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ABSTRACT 


This  thesis  examines  the  broad  issues  and  concepts  which  impact  the  effectiveness  of  U.S. 
Air  Force  deployable  communications.  A  high-level  "systems  analysis"  approach  was  used  in  this 
study  to  gain  visibility  on  the  number  of  elements  involved  Ln  deployable  communications  and 
their  interrelationships.  Previous  studies  were  reviewed  to  determine  where  trends  existed,  and 
contemporary  analysis  efforts  were  examined  for  clarity  and  cohesiveness.  The  principles  of 
command  and  control  are  discussed,  followed  by  a  description  of  the  current  family  of  U.S.  Air 
Force  deployable  communications  equipment  and  how  it  supports  the  warfighters  in  the  deployed 
environment  Central  issues  and  concepts  are  developed  through  trade-off  analysis  and  illustrative 
examples.  Key  concepts  include:  time  phased  arrival  of  equipment  in  theater,  modularity  of 
design,  strategic/tactical  interface,  and  interoperability.  Conclusions  indicate  that  persistent 
systems  integration  problems  are  more  the  result  of  organizational  and  conceptual  problems  than 
with  the  physical  technologies.  Recommendations  include  the  establishment  of  a  "center  of 
excellence"  to  coordinate  and  facilitate  systems  integration.  The  tools  for  such  a  center  include 
clear  policy  direction,  computer  models  and  simulations,  trade-off  analysis,  and  artificial 
intelligence/expert  systems.  A  conceptual  architecture  is  provided  to  illustrate  the  desired 
relationship  between  cooperative  sub-architectures,  and  a  definition  proposed  for  architectures  in 
an  attempt  to  standardize  its  interpretation. 
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L  INTRODUCTION 


A.  BACKGROUND 

The  motivation  for  this  thesis  stems  from  years  of  frustration  on  the  part  of  the 
author  to  gain  an  insight  into  how  to  "integrate"  deployable  communications  systems. 
Integrate  is  set  off  in  quotes  because  the  word  can  mean  many  things  to  many  people. 
In  this  context,  it  will  be  taken  to  parallel  the  ideas  from  systems  theory,  which  states: 

•  The  whole  is  more  than  the  sum  of  parts, 

•  The  whole  determines  the  nature  of  the  parts, 

•  The  parts  cannot  be  understood  if  considered  in  isolation  from  the  whole,  and 

•  The  parts  are  dynamically  interrelated  and  interdependent.  [Ref.  l:p.  10] 

This  means  that  communications  support  is  more  than  just  a  set  of  wires  between 
two  points.  Integration  concepts  should  encompass  not  only  the  technical  aspects  of 
communications,  but  also  the  management  and' organizational  structures  which  ultimately 
enable  the  wires  to  exist 

Pre-thesis  research  indicated  that  the  above  concept  was  still  not  very  prevalent 
among  those  who  are  charged  with  the  responsibility  to  manage  deployable  systems.  This 
is  somewhat  understandable  given  the  nature  of  the  task.  Communications  systems 
themselves  are  complex.  They  are  the  single  common  denominator  throughout  a  theater; 
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every  functional  area  is  affected  by  communications.  This  makes  the  gaining  of 
consensus  among  users  challenging  due  to  differing  opinions  of  priorities  and 
requirements.  Further,  while  the  management  mechanism  used  to  eventually  field  a 
system  seems  to  have  structure  in  theory,  the  execution  is  frequently  considered 
fragmented  in  actual  operation. 

As  such,  there  are  two  separate  threads  that  run  through  this  thesis:  the  fundamental 
issues  relating  to  the  physical  process  of  providing  communications,  and  the 
organizational  issues  which  impact  the  Air  Force’s  ability  to  put  those  physical  systems 
in  place.  They  are  distinct,  yet  intertwined,  and  systems  theory  maintains  both  must  be 
understood  if  the  "whole"  of  deployable  communications  is  to  be  understood. 

B.  TERMS 

Many  terms  have  come  to  be  associated  with  communications  over  the  years. 
Command  and  control,  or  C2,  is  frequently  joined  with  communications  to  form  C3. 
Later,  computers  and  intelligence  were  added  to  C3  to  form  CT.  All  terms  are  used  in 
this  paper  primarily  due  to  the  thrust  of  the  source  documents.  While  the  terms  are  not 
exactly  interchangeable,  the  frequent  use  of  C3  and  C*I  in  documents  illustrates  the 
interdependence  of  elements.  This  thesis  will  consider  communications  as  the  bridge 
between  where  information  is  processed  (computers  and  intelligence)  and  where  it  is  used 
to  make  decisions  (command  and  control). 
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C.  SCOPE 


Tackling  a  project  such  as  this  forced  the  focus  to  remain  at  a  fairly  high  level. 
Any  single  issue  could  lend  itself  to  in-depth  analysis.  But  the  challenge  is  not  one  of 
solving  individual  problems,  it  is  one  of  integrating  all  of  those  solutions  into  a  larger, 
workable  whole.  In  our  case,  it  is  the  communications  supporting  the  warfighter  in  a 
deployed  environment.  To  stay  manageable,  the  scope  was  generally  limited  to  Air  Force 
systems,  with  the  understanding  that  the  Air  Force  systems  are  themselves  part  of  a 
larger,  joint  system. 

D.  OVERVIEW  BY  CHAPTER 

Chapter  II  is  a  review  of  three  previous  studies  of  deployable  communications.  The 
objectives,  findings,  and  recommendations  of  the  studies  are  discussed  and  summarized. 

Chapter  HI  provides  a  snapshot  of  the  joint  and  USAF  views  of  architectures.  The 
development  flows  from  high  level  guidance  from  the  joint  staff  through  to  the  directives 
which  stipulate  the  Air  Force  deployable  communications  architecture. 

Chapter  IV  describes  deployable  systems  at  present.  This  includes  a  detailed 
description  of  the  tactical  air  control  system  (TACS),  and  the  communications  equipment 
which  supports  the  TACS  and  the  tactical  air  base.  Shortfalls  and  trends  highlighted  from 
Operation  Desert  Storm  are  discussed  briefly. 

Chapter  V  explores  the  central  issues  and  concepts  which  must  be  addressed  in 
developing  a  deployable  communications  architecture.  The  emphasis  is  on  understanding 
the  interrelationships  between  the  issues  to  facilitate  and  stimulate  informed  decisions 
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regarding  the  potential  shape  of  future  systems.  Policy,  type  of  conflict  to  plan  for, 
phasing  of  equipment  arrival,  modularity,  and  distributed  processing  are  key  issues. 

Chapter  VI  provides  a  summary  of  the  research  and  recommendations  to  enhance 
systems  integration  of  deployable  communications  for  the  future. 
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IL  REVIEW  OF  STUDIES 


Three  studies  were  reviewed  to  provide  a  foundation  for  the  balance  of  this  research.  While 
they  differed  somewhat  in  their  approach  and  assumptions,  they  were  remarkably  consistent  in 
their  findings  and  recommendations. 

A.  BACKGROUND  AND  OBJECTIVES 

The  studies  reviewed  were  completed  between  1985  and  1991,  and  all  were  sponsored  by  the 
Air  Force  Systems  Command  (AFSC). 

1.  Twenty-First  Century  Tactical  Command  and  Control  (TC2-21) 

This  study  was  conducted  in  1985  by  a  group  of  industry  and  DoD  personnel.  Their 
intention  was  to  "...develop  an  architectural  framework  for  tactical  command  and  control  (C2)  for 
the  early  twenty-first  century  period...to  guide  development  of  a  survivable  and  sustainable 
tactical  C2  capability...",  all  against  a  NATO  backdrop.  Important  assumptions  were: 

•  Basic  USAF  mission  and  doctrine  (as  stated  in  Air  Force  Manual  1-1)  would  not  change 

•  Basic  tactical  C2  functions  do  not  change,  although  the  execution  and  environment  could 

•  The  threat  and  C2  structure  from  the  NATO  central  region  provided  the  baseline  of 
consideration  to  establish  maximum  requirements  of  performance 

•  The  likelihood  of  worldwide  contingency  deployments  established  the  need  for  modularity, 
flexibility,  and  transportability  [Ref.  2:p.  I- 1] 
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2.  Tactical  Battle  Management  (TBM) 

This  study,  along  with  the  U.S.  Air  Force  Tactical  Communications  study,  was 
conducted  by  the  Air  Force  Studies  Board  (AFSB).  The  TBM  study  was  completed  in  1986,  but 
the  report  was  not  published  until  1990  due  to  changing  priorities  (as  a  result  of  a  changing 
world  political  climate).  Scope  was  limited  to  conventional  tactical  air  missions  for  Europe  and 
Southwest  Asia.  Their  task  was  as  follows: 

•  Examine  the  operational  requirements,  independent  of  the  present  or  likely  capability  to 
satisfy  those  needs 

•  Survey  and  project  the  technology  relevant  to  decision-aiding  information  technology 

•  Match  the  capabilities  to  the  needs 

•  Review  the  current  programs  and  acquisition  process 

•  Recommend  ways  to  facilitate  the  development  of  effective  TBM  aids  and  related 
technology  [Ref.  3:p.  1] 

What  this  amounts  to  is  to  find  out  where  the  Air  Force  can  apply  decision  aids  to 
assist  in  TBM,  and  then  determine  how  to  put  those  tools  in  place. 

3.  U.S.  Air  Force  Tactical  Communications 

Completed  in  1991,  this  study  was  an  extension  of  the  earlier  TBM  study.  While  the 
TBM  study  recognized  communications  as  an  important  element  in  TBM,  the  panel  was  not 
chartered  or  structured  to  examine  it  in  detail.  This  study  focused  specifically  on  tactical 
communications  support  to  battle  management.  By  agreement  with  the  sponsor,  scope  was 
limited  to  reviewing  the  USAF’s  ability  to  meet  the  needs  of  its  contingency  forces.  Their  task 
was: 


6 


•  Evaluate  planned  tactical  communications  capabilities,  with  particular  emphasis  on  joint- 
service  and  multi-national  interoperability 

•  Examine  the  technological  command  and  control  requirements 

•  Recommend  future  concepts  for  application 

•  Propose  an  implementation  strategy  [Ref.  4:p.  5] 

B.  SIGNIFICANT  FINDINGS 

1.  TC*-21 

This  study  determined  that  physical  dispersal  and  functional  distribution  would  be  key 
to  survivability  for  deployed  systems.  Figure  1  helps  to  illustrate  this  point.  From  a  topology 
standpoint,  the  greater  the  separation  between  elements,  the  greater  the  difficultly  in  locating  and 
targeting  them.  For  functional  distribution,  their  idea  was  to  provide  redundancy  through 
spreading  the  functions  throughout  the  theater  versus  concentrating  them  in  focused  elements. 
In  this  way,  if  one  part  of  the  network  is  disabled,  another  part  can  assume  its  workload.  This 
helps  eliminate  single  points  of  failure.  In  addition,  to  take  full  advantage  of  technology,  manual 
methods  of  battle  management  must  give  way  to  using  automated  decision-support  capabilities. 
Finally,  the  need  for  rapid  deployment  will  drive  a  "building-block",  modular  C2  approach  for 
transportability  and  for  allowing  incremental  levels  of  capability  as  required.  [Ref.  2:p.  ii] 

2.  Tactical  Battle  Management  (TBM) 

The  TBM  study  found  that  current  technology  would  meet  the  USAF’s  needs,  but  must 
be  integrated  into  the  Tactical  Air  Control  System  (TACS)  to  be  effective.  This  is  being 
accomplished  through  programs  such  as  the  Modular  Tactical  Air  Control  Center  (MTACC),  the 


7 


Centralized 


Dedicated  support  to  each  function/fadlity 
No  replication  of  functions 
I  (redundant  central  processors 
Many  single-point  failures 
Readily  distinguishable  signatures 
Limited  modularity 
Limited  interoperability 

Low  bandwidth,  point-to-point  communications 


Fully  Distributed 


Single  common  support  clement 
Theater  wide  function  replication 
Elimination  of  single  point  failures 
No  dtadngulahabie  signatures 
Universal  modules 
High  Interoperability 
High  communication  loads 

Semi-Distributed 


Limited  desses  of  support  elements 
Dispersed  rspScatlon  of  functions 
Elimination  of  single  point  failures 
Minimal  distinguishable  signature# 
Classes  of  modules 
Moderate  communication  loads 


Figure  1:  Architectural  Options  [Ref.  2:p.  Ill- 19] 
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Contingency  TACS  Automated  Planning  System  (CTAPS),  and  the  Modular  Control  Element 
(MCE).  However,  they  stated  the  current  development  and  acquisition  system  does  not  get  this 
new  technology  into  the  field  fast  enough  to  meet  the  Air  Force’s  needs  for  TBM.  It  takes  too 
long,  and  items  are  frequently  outdated  by  the  time  they  are  fielded.  It  was  pointed  out  that  an 
acquisition  system  which  works  well  for  weapon  systems  does  not  provide  the  flexibility  needed 
when  technologies  are  rapidly  evolving.  Finally,  the  lack  of  coordinated  effort  to  field  essential 
systems  has  severely  impacted  the  Air  Force’s  ability  to  manage  tactical  air  warfare.  [Ref.  3:pp. 
3-4] 


3.  U.S.  Air  Force  Tactical  Communications 

This  study  highlighted  discrepancies  in  the  areas  of  testing,  architecture  and  engineering. 

They  found  that  communications  systems  were  not  stressed  during  testing  in  a  way  that  would 

be  typical  of  a  warlike  environment.  This  may  be  at  least  partially  related  to  the  next  point  of 

there  being  a  lack  of  knowledge  regarding  the  network  loading  demands  which  might  be 

experienced  under  warlike  conditions.  Without  this  information,  it  is  difficult  to  realistically 

stress  a  network  during  testing  or  exercises.  Finally,  they  noted  there  is  a  lack  of  adequate 

systems  architecture  and  systems  engineering.  According  to  the  report: 

Planning,  development,  and  management  of  the  tactical  communications  system  has  been 
and  is  fragmented  and  dispersed  among  several  organizations.  The  Air  Force  must 
establish  a  structure  for  TBM,  including  the  supporting  communications,  so  that  the 
developing  technologies  and  the  evolving  command,  control,  communications,  and 
intelligence  capabilities  ’fit’  into  and  contribute  to  the  overall  system.  [Ref.  4:p.  8] 
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C.  RECOMMENDATIONS 


The  study  recommendations  fell  into  two  broad  categories:  those  that  related  to  the 
management  of  the  systems  (development,  acquisition,  and  implementation)  and  those  that  were 
concerned  with  the  technical  means  of  providing  deployed  command  and  control. 

1.  Management  Issues 

The  number  one  issue  from  all  studies  was  that  a  tactical  C2  or  battle  management 
architect  must  be  designated  and  given  clear  responsibility  and  authority  to  accomplish  the  task 
of  systems  integration.  It  was  noted  that  the  process  of  design  and  implementation  of  systems  was 
fragmented  among  many  different  offices,  and  no  single  agency  was  responsible  for  oversight  and 
integration  of  the  various  efforts  [Ref.  2:p.  IV-1,  Ref.  3:p.  4,  Ref.  4:p.  13].  The  TBM  study 
along  with  the  TC2-21  were  critical  of  the  development,  acquisition,  and  testing  arenas.  TBM 
suggests  a  better  interaction  between  the  users  and  developers  since  requirements  tend  to  be 
dynamic  and  difficult  to  state  in  detail.  Rapid  prototyping  and  field  testing  (what  they  call  "build 
a  little,  test  a  little")  will  ultimately  be  the  key  to  successful  development  [Ref.  3:p.  4].  TC2-21 
pointed  out  the  need  for  a  comprehensive  test  bed.  At  the  time  of  its  writing,  equipment  and 
expertise  were  spread  across  the  country.  Little  if  any  networking  existed  to  tie  these  sites 
together  [Ref.  2:p  IV-3].  While  the  National  Test  Bed  (NTB)  concept  seeks  to  tie  research, 
development  and  operations  sites  together  through  a  distributed  network,  it  is  unclear  if  TC2-21 
was  a  motivating  factor.  The  USAFTC  study  further  suggested  rapid  prototyping  and  field 
testing  as  part  of  the  evolutionary  acquisition  approach  [Ref.  4:p.  14].  Table  1  summarizes  these 
and  the  following  recommendations. 
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2.  Technical  Issues 


While  not  a  specific  recommendation  except  from  the  TC2-21  study,  all  reports  noted 
that  simply  using  many  of  the  equipments  and  concepts  already  available  in  the  private  sector 
will  provide  the  ability  to  field  smaller,  lighter,  and  more  modular  equipment.  The  USAFTC 
study  points  out  that  much  of  our  current  equipment  is  based  on  1960’s  technology  [Ref.  4:p.  9]. 
Advances  in  electronics  and  packaging  (large  scale  integration  of  components)  since  that  time 
have  yielded  large  reductions  in  size  and  weight.  Finally,  the  USAFTC  states  the  tactical  C3 
system  must  remain  robust  under  operational  stress  and  continue  to  fulfill  its  essential  missions. 
To  do  this  requires  knowledge  of  the  missions,  expected  degradations  under  stress  and  enemy 
countermeasures,  and  loading  of  the  supporting  communications  network.  [Ref.  4:p.  14] 


TABLE  1:  SUMMARY  OF  STUDY  RECOMMENDATIONS 


RECOMMENDATIONS 

TC2-21 

TBM 

TC 

1.  Integrate  planning  &  C2  architectures 

XX 

XX 

XX 

2.  Greater  flexibility  and  user  interface  in  develop¬ 
ment,  acquisition,  and  testing 

XX 

XX 

XX 

3.  Comprehensive  testing 

XX 

XX 

4.  Develop  smaller,  lighter,  more  modular 
equipment 

XX 

5.  Robust  network  under  stress 

XX 

D.  SUMMARY 

The  studies  reviewed  all  made  the  point  of  needing  to  designate  a  systems  architect  and 
engineer,  and  to  vest  in  them  the  authority  to  integrate  the  many  aspects  of  systems  design  as  it 
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is  currently  performed.  Rapid  prototyping  and  field  testing,  and  greater  use  of  commercially 
available  items  will  also  speed  the  transfer  of  higher  technology  equipment  into  the  Air  Force’s 
deployable  communications  systems. 
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IH.  ARCHITECTURES 


This  chapter  is  an  overview  of  the  joint  and  Air  Force  concepts  and  architectures 
which  are  currently  guiding  the  planning  and  implementation  of  deployable  systems. 

A.  C4I  FOR  THE  WARRIOR 

0*1  for  the  Warrior  (referred  to  in  this  section  as  simply  C1!)  is  a  concept  paper 
developed  by  the  Joint  Staff/J-6  office  [Ref  5].  It  provides  a  high  level  view  of  what  is 
expected  for  the  warrior  and  how  to  transition  current  systems  toward  that  goal. 

1.  Concept  and  Goal 

The  idea  behind  C4!  is  to  take  a  top-down  approach  to  integrating  technology 
into  deployable  systems,  versus  the  usual  bottom-up  approach  which  can  introduce  new 
technology  quickly  but  tends  to  fragment  its  implementation.  The  result  of  the  bottom-up 
approach  has  been  the  fielding  of  a  great  deal  of  helpful  equipment,  but  much  of  it 
operates  in  a  stand-alone  mode,  overloading  the  warfighter  with  too  much  information  that 
is  uncorrelated  between  sources.  This  is  unacceptable  in  a  era  of  increasing  emphasis  on 
joint  operations.  The  ultimate  goal  of  C*I  is  to  provide  "...a  fused,  real  time,  ground  truth 
picture  of  [the  warrior’s]  battle  space  and  the  ability  to  order,  respond  and  coordinate 
horizontally  and  vertically  to  the  degree  necessary  to  prosecute  his  mission  in  that  battle 
space."  While  many  elements  must  work  together  to  make  this  happen,  the  focus  in  this 
document  was  only  on  equipment,  not  on  procedures  or  doctrine.  [Ref.  5:p.  2] 
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2.  The  Road  Map 


While  many  architectures  provide  a  view  of  systems  on  the  horizon  that  will 
be  all  things  to  all  users,  C4!  argues  that  none  will  provide  the  needed  interoperability 
today.  What  is  needed  is  an  affordable  way  to  make  the  current  systems  interoperate  to 
give  our  warfighters  the  needed  edge.  With  an  ideal  of  being  able  to  pull  from  the  ether 
whatever  the  warfighter  needs,  C4!  states  that  standardizing  our  information  exchange  will 
enable  us  to  gain  the  needed  interoperability  and  provide  the  required  "picture"  for  the 
warrior. 

The  single,  overriding  fact  is  that  interoperable  systems  must  exchange  information. 
The  foundation  needed  for  interoperability  is  formed  by  defining  the  criteria  to 
exchange  information.  THE  STANDARD  that  ir  .it^ued  is  a  very  straight  forward 
definition  of  the  communications  protocol  anu  data  format  required  to  input  and 
extract  information  from  the  ’data  base  in  the  ether.’  [Ref.  5:pp.  5-6] 

There  are  a  number  of  advantages  to  making  existing  systems  interoperable 
through  information  exchange.  The  primary  reason  is  that  the  cost  becomes  reasonable- 
instead  of  entirely  new  systems,  only  interfaces  need  to  be  built  to  allow  existing  systems 
to  talk.  In  addition,  existing  systems  are  already  performing  the  missions  assigned  and 
commanders  are  comfortable  with  them.  What  is  needed  is  to  enhance  their  "picture" 
through  greater  access  to  a  more  extensive  data  base.  The  point  is  made  that  for 
survivability  reasons,  the  "data  base  in  the  ether"  should  not  be  a  single  data,  base,  but 
rather  a  distributed  data  base.  Service  architectures  would  fit  under  this  concept  simply 
by  meeting  the  communications  protocols  and  data  formats  established  within  the  data 
base.  [Ref.  5:p.  6] 
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0*1  accepts  that  getting  "from  here  to  there"  will  still  be  a  long,  costly 
process,  but  insists  that  the  goals  must  be  set  today  and  adhered  to,  or  else  they  will  never 
be  achieved.  The  focus  will  be  on  concepts  such  as  open  systems  architecture,  pull  of 
information  (from  the  data  base)  versus  pushing  everything  into  a  commander  and  letting 
him  sort  it  out,  data  standards,  fusion  of  intelligence,  and  tools  such  as  expert  systems  and 
artificial  intelligence  to  enable  construction  of  the  ultimate  architecture.  [Ref.  5:p.  6] 

3.  Moving  Toward  the  Goal 

CT  outlined  three  areas  that  will  provide  the  means  to  realize  the  goal  of 
interoperablity  between  existing  systems  and  the  long  range  architecture:  standards,  use 
of  resources,  and  testing. 

a.  Standards 

An  instrumental  factor  in  defining  standards  has  been  the  establishment 
of  the  Defense  Information  Systems  Agency  (DISA)  (and  the  Joint  Interoperability 
Engineering  Organization  (JIEO)  within  DISA)  as  the  single  focal  point  within  DoD  for 
standards.  Getting  this f  <  c  cept  institutionalized  will  require  all  of  the  CINCs  and  services 
to  use  the  DISA  standards.  In  addition,  the  standards  must  be  kept  as  simple  as  possible. 
The  example  of  60  cycle,  115  volt  household  electricity  is  used  as  an  analogy.  The 
rationale  is  that  keeping  the  standards  simple  will  keep  program  costs  down.  [Ref.  5:p. 
7] 
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b.  Use  of  Existing  Resources 

A  suggested  starting  point  for  an  interoperability  program  would  be  to 
examine  the  existing  data  formats  currently  in  use,  as  well  as  those  that  industry  can 
offer.  Studying  the  current  information  set  may  allow  correlation  of  some  elements  into 
an  ultimately  smaller  and  more  clearly  defined  set  of  data  elements.  The  desire  is  to  keep 
that  set  as  small  as  possible.  Some  standards  may  be  able  to  be  used  as  is,  while  others 
might  need  slight  or  even  complete  modification.  Once  the  standard  is  defined,  the  issue 
of  compliance  comes  up.  Compliance  will  be  the  responsibility  of  the  system  owners, 
and  will  be  verified  through  testing.  [Ref.  5:pp.  7-8] 

c.  Testing 

Just  as  a  focal  point  has  been  appointed  for  standards,  the  Joint 
Interoperability  Test  Center  (JITC)  at  Fort  Huachuca,  AZ  will  be  the  focal  point  for 
interoperability  testing.  The  recommendation  is  to  make  testing  an  early  priority  in 
program  life.  Eventually,  the  JITC  will  have  a  distributed  test  capability  which  will  no 
longer  require  the  equipment  to  be  physically  located  at  their  premises.  Testing  will  be 
possible  through  "dial-in"  connectivity  aimed  at  making  compliance  easier  and  earlier  in 
program  development  [Ref.  5:p.  8] 

B.  JOINT  INTEROPERABILITY  ENGINEERING  ORGANIZATION 
ARCHITECTURES 

The  Joint  Interoperability  Engineering  Organization  (JIEO)  serves  as  the  DoD 
systems  engineer  for  C4  information  systems.  In  this  capacity,  they  look  primarily  at 
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interoperability  issues  between  forces  supporting  the  deployed  CINCs.  They  look  at 
architectures  from  three  standpoints:  long-range  objective,  CINC  interoperability,  and 
functional  interoperability.  [Ref.  6] 

The  long-range  objective  architecture  program  reviews  the  current  and  long-range 
service  architectures  for  potential  duplication  or  interoperability  problems.  JIEO  hosted 
an  objective  architecture  conference  in  September  1991  where  the  services  briefed  their 
conceptual  architectures  and  discussed  potential  interoperability  problems.  [Ref.  6] 

The  CINC  interoperability  program  reviews  the  C4  requirements  of  the  CINC,  and 
identifies  the  elements  that  will  provide  C4  support.  These  elements  could  be  U.S.  forces. 
Federal  agencies,  or  allied/coalition  forces.  Assessments  of  C4  capabilities  are  made, 
deficiencies  identified,  solutions  recommended,  and  a  detailed  implementation  plan 
developed.  [Ref.  6] 

The  functional  interoperability  program  focuses  on  specific  mission  areas  and  is  not 
limited  in  scope  to  a  specific  CINC.  Again,  an  assessment  of  current  capabilities  is  made, 
deficiencies  identified,  solutions  recommended,  and  an  implementation  plan  developed. 
[Ref.  6] 

Because  the  products  developed  are  generally  classified,  no  diagrams  are  included 
in  this  paper.  In  addition,  many  of  the  documents  are  under  revision  in  an  attempt  to 
standardize  the  information  provided.  Eventually,  these  documents  will  serve  as  the 
design  model  for  C4  systems  in  the  joint  environment.  [Ref.  6] 
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C.  AIR  FORCE  COMMUNICATIONS. COMPUTER  SYSTEMS 


ARCHITECTURE 

Guidance  for  the  Air  Force  Communications-Computer  Systems  (C-CS)  Architecture 

is  contained  in  Air  Force  Pamphlet  700-50,  Volume  I.  It  ensures  that: 

...validated  communications-computer  systems  requirements  are  satisfied  with 
integrated,  affordable  solutions.  [An  architecture’s]  purpose  is  to  provide  standards, 
systems,  protocols,  interfaces,  and  so  forth,  that  must  be  considered  when 
developing,  implementing,  or  modifying  Air  Force  communications-computer 
systems.  [Ref.  7:p.  3] 

The  intent  of  the  architecture  is  to  keep  "today’s  innovative  solution"  from 
becoming  tomorrow’s  integration  nightmare. 

1.  Background 

The  need  for  an  architecture  is  driven  by  the  number  of  systems  introduced 
by  the  various  communities  (whether  functional  area,  base-  or  command-level,  or  Air 
Force  wide,  or  those  supporting  weapons  systems)  to  meet  unique  needs.  Without  a  plan, 
all  compete  for  the  same  limited  resources  of  dollars,  cable  plant,  and  space,  and  with 
little  regard  toward  interoperation  with  other  systems.  [Ref.  7:p.  3] 

This  situation  occurred  as  an  outgrowth  of  the  rapid  expansion  of  technology 
over  the  last  20  years.  As  users  have  become  more  literate  in  the  new  technologies,  they, 
in  turn,  developed  new  applications  to  automate  and  enhance  their  operations.  Finally, 
as  products  became  available,  requirements  tended  to  be  written  in  terms  of  hardware 
desired,  not  a  capability.  Frequently,  the  technical  community  was  not  consulted  for  ways 
to  satisfy  the  requirement.  [Ref.  7:p.  3] 
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The  700-series  regulations  outline  a  process  and  family  of  documents  to 
provide  the  guidance  needed  to  pull  all  of  the  elements  together.  They  move  from  the 
more  abstract  "vision"  outlined  in  the  Planning  and  Architectural  Guidance  (a  ten  year 
planning  horizon)  to  the  defined  roadmaps  that  will  provide  the  goal  architecture,  and 
finally  the  programming  and  implementation  phases  which  work  in  shorter  horizons  and 
more  concrete  terms.  [Ref.  7:pp.  4-5] 

2.  Architectural  Development  Fundamentals 

There  are  certain  goals,  attributes,  key  concepts,  and  common  processes  which 
must  span  all  C-CS  efforts.  Goals  provide  the  common  direction  for  all  levels  as  systems 
are  reviewed  for  improvement  The  goals  of  the  Air  Force  C-CS  architecture,  and  the 
more  specific  objectives  which  support  them  are  shown  in  Tables  2  and  3.  [Ref.  7:p.  8] 

a.  Attributes 

An  architecture  must  have  influence  if  it  is  to  affect  the  long-term  C3I 
infrastructure.  It  must  also  provide  a  structure  to  guide  the  entire  life  cycle  of  a  program 
and  its  equipment.  The  focus  must  be  on  wartime  requirements,  and  it  must  specify 
systems  which  will  meet  military  requirements  even  in  an  era  of  fiscal  contraction.  [Ref. 
7:p.  8] 
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TABLE  2:  AF  C-CS  ARCHITECTURAL  GOALS  [Ref.  7:p.  8] 


GOALS 

l.  Ensure  mission  essential  needs  for  communications-computer  systems  are  supported. 

2.  Exploit  information  as  a  resource  to  enhance  mission  effectiveness  and  efficiency  in  both  wartime  and  peacetime. 

3.  Ensure  mission-essential  communication-computer  systems  are  as  functionally  survivable  and  enduring  in  stressed 
environments  as  the  forces  supported. 

4.  Ensure  communications-computer  systems  which  process  sensitive  information  provide  an  adequate  level  of  information 
protection. 

5.  Exploit  technology  to  improve  the  effectiveness  and  efficiency  of  communications-computer  systems  to  meet  Aar  Force 
wartime  and  peacetime  mission  requirements. 

TABLE  3:  AF  C-CS  ARCHITECTURAL  OBJECTIVES  [Ref.  7:p.  8] 

OBJECTIVES 

1  Focus  the  efforts  cf  communications-computer  systems  organisations  to  provide  better  end-user  support. 

2.  Enhance  communications-computer  systems  support  to  end-users  to  increase  mission  effectiveness  or  permit  reduction  in 
resource  requirements. 

3.  Provide  end  users  with  powerful ,  flexible,  integrated  tools  to  improve  responsiveness. 

4.  Enhance  user  friendliness  of  communications-computer  systems  to  reduce  training  requirements  associated  with  their  use. 

5.  Provide  modem,  machine-independent  software  engineering  tools  to  expedite  development  of  major  systems. 

6.  Increase  portability  through  " open  systems." 

b.  Key  Concepts 

(!)  Understanding  the  User  Requirement.  Understanding  the  user 
requirements  (what  they  call  "user  information  needs")  entails  information  flows,  possible 
stress  points,  and  the  impact  of  environmental  dynamics.  Requirements  should  be  stated 
in  terms  of  mission  needs,  and  not  in  terms  of  specific  hardware  or  technologies.  [Ref. 
7:p.  81 
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(2)  Interoperability.  Since  data  frequently  moves  from  one  system 
to  another,  systems  must  be  interoperable  and  compatible  with  each  other  at  the  boundary. 
As  more  systems  are  interconnected,  the  technical  architecture  should  guide  system  design 
to  ensure  interoperability  at  the  time  of  implementation.  [Ref.  7:p.  9] 

(3)  Open  Systems.  Open  systems  allow  equipment  from  many 
different  manufacturers  to  co-exist  and  interoperate.  With  renewed  emphasis  on  fully 
competitive  contract  awards,  the  C-CS  environment  will  have  even  greater  vendor 
diversity  in  the  future.  The  layered  approach  in  open  systems,  which  specifies  where 
certain  technical  functions  are  performed,  provides  the  ground  rules  any  new  system  must 
meet  [Ref.  7:p.  9] 

(4)  Distributed  Processing.  The  idea  here  is  to  move  the  information 
as  little  as  possible  and  keep  it  as  close  as  possible  to  the  user  to  meet  their  needs.  The 
pamphlet  suggests  a  robust  shared  network  of  interconnections  to  facilitate  distributed 
processing  and  standards  to  define  information  exchange  to  minimize  data  conversions. 
[Ref.  7:p.  9] 

c.  Common  Processes 

All  architectures,  regardless  of  nature  or  scope,  are  to  follow  the  same 
basic  development  process.  The  steps  are  as  follows: 

1.  Describe  the  baseline  architecture, 

2.  Identify  system  requirements, 

3.  Identify  key  factors  that  affect  the  architecture. 
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4.  Develop  a  target  architecture, 

5.  Define  an  evolutionary  path,  and 

6.  Develop  acquisition  and  implementation  strategies  to  reach  the  target.  [Ref.  7:p.9] 

3.  Target  Architecture 

The  target  architecture  is  shown  in  Figure  2,  and  is  expected  to  employ 
concepts  stated  earlier  in  a  "system  of  systems  which  will  be  robustly  interconnected  to 
responsively  serve  all  users."  The  target  does  not  carry  a  specific  time  for  implementation, 
but  most  of  the  features  are  expected  to  be  in  place  by  the  year  2010.  [Ref.  7:p.  11]  The 
target  will  use  the  concepts  of  open  systems,  multi-level  security,  and  centralized 
communications  with  distributed  processing.  Data  and  software  are  to  be  standardized 
to  enable  the  sharing  of  resources  (such  as  data  elements)  and  reduce  duplication  of  effort. 
[Ref  7:p.  14]  The  interplay  between  the  "building  blocks"  used  in  the  development  of 
the  architecture  is  illustrated  in  Figure  3. 

Each  building  block  is  also  a  "technical  architecture"  documented  in  additional 
volumes  of  AFP  700-50.  Because  many  of  the  technical  architectures/building  blocks 
appear  in  the  architecture  of  interest  (deployable  systems)  it  is  helpful  to  briefly  explain 
the  role  of  each. 
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Long  Haul  Gateways 
DON 
DSN 


Figure  2:  Target  Architecture  (Ref.  7:p.  1 1] 
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End-User  Terminals 


Figure  3:  Architectural  Building  Blocks  [Ref.  7:p.  12] 

a.  Deployable  Communications-Computer  Systems 

Deployable  systems  support  a  wide  range  of  users  through  switching 
equipment,  transmission  media,  and  access  to  common-user  systems  in  a  deployed 
environment.  They  provide  both  intra-  and  inter-theater  connectivity  through  either  local 
or  long-haul  information  transfer.  [Ref.  7:p.  11] 

b.  Data  Management 

Data  management  sets  up  the  standards  which  allow  different 
applications  programs  running  on  different  hardware  the  ability  to  share  data  as  a 
corporate  resource.  [Ref.  7:p.  1 1  ] 
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c.  Local  Information  Transfer 

Local  information  transfer  is  the  movement  of  voice,  data,  video,  and 
other  services  within  a  base  environment.  [Ref.  7:p.  11] 

d.  Long-Haul  Information  Transfer 

Long-haul  systems  provide  connectivity  to  the  common-user  systems 
managed  by  DISA,  and  dedicated  command  and  control  systems  which  reside  outside  the 
intrabase  environment.  [Ref.  7:p.  13] 

e.  Integrated  Systems  Control 

Integrated  systems  control  provides  the  equipment  and  procedures  to 
monitor  and  troubleshoot  network  facilities  as  needed.  It  serves  as  a  technical  control 
point  for  fault  isolation  and  detection  at  base  level.  [Ref.  7:p.  13] 

/.  Software 

Future  software  acquisition  and  development  will  be  based  upon 
commercial  products  already  available,  Ada  (the  DoD  standard  language),  and  standard 
databases,  tools,  and  supporting  languages.  Configuration  control  will  continue  to  be  a 
priority.  [Ref.  7:p.  13] 

g  Security 

The  objective  of  security  is  to  protect  information  from  either  physical 
or  electronic  compromise.  Technical  and  procedural  measures  are  employed  to 
accomplish  this  task.  [Ref.  7:p.  13] 
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h.  Automated  Support  Systems 

This  area  includes  the  dedicated  and  shared-use  computer  systems  in  the 
base  environment,  with  a  focus  on  standard  systems.  Computers  can  be  those  acquired 
from  standard  requirements  contracts  or  from  other  sources.  An  example  of  the  current 
automated  support  systems  is  shown  in  Figure  4.  [Ref.  7:p.  13] 

The  above  concepts  all  support  the  overall  Air  Force  C-CS  architecture. 
Deployable  systems  naturally  use  many  of  the  same  building  blocks  to  develop  the  sub¬ 
architectures  used  to  support  deployed  forces.  The  deployable  C-CS  architecture  is 
discussed  next. 
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D.  AIR  FORCE  DEPLOYABLE  C  CS  ARCHITECTURE 

The  Air  Force  Deployable  C-CS  Architecture  (DCSA),  as  stated  in  AFP  700-50, 
Volume  II,  provides  the  technical  structure  to  realize  the  target  architecture  and  defines 
an  evolutionary  path  to  follow.  The  document  parallels  the  steps  outlined  in  Section 
m.C.2.c  in  providing  background,  the  current  baseline,  the  target,  and  an  evolutionary 
strategy.  The  background  is  similar  to  that  presented  earlier,  so  will  not  be  repeated. 

1.  Current  Baseline 

The  current  baseline  of  equipment  is  as  depicted  in  Figure  5.  The  equipment 
provides  the  supporting  infrastructure  for  control  of  combat  air  forces,  airlift  assets,  and 
the  main  operating  bases  (MOB’s).  [Ref.  8:p.  10]  The  present  deployable  systems  are 
covered  in  greater  detail  in  Chapter  IV. 

2.  Target  Architecture 

The  target  architecture  is  designed  to  overcome  shortfalls  in  the  areas  of 
voice,  data,  and  transmission  systems  through  an  integrated,  digital,  common-user, 
distributed  network.  Commercially  available  technologies  and  standards,  coupled  with 
open  systems  will  be  used  to  the  maximum  extent  possible.  Components  should  be  the 
same  as  their  fixed-station  counterparts,  or  re-packaged  (but  not  re-designed)  to  meet 
unique  military  requirements.  [Ref.  8:p.  28]  The  target  architecture  is  centered  around 
an  Information  Transfer  Node  (ITN).  The  ITN  serves  to  route  information  packets  and 
performs  network  functions.  Concepts  presented  during  Chapter  II  are  also  included,  i.e., 
modularity  and  distributed  systems.  Figure  6  shows  how  an  ITN  acts  as  "the  primary 
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UNIT  LEVEL 


NODAL  LEVEL 


LONG-HAUL  LEVEL 


Figure  5:  Current  Deployable  C-CS  Architecture  [Ref.  7:p.  12] 

building  block"  for  intrabase  communications.  Each  topology  will  be  tailored  to  the 
specific  needs  of  the  attached  users.  [Ref.  8:p.  37]  Groups  of  users  are  further 
interconnected  across  the  deployed  base  through  a  communications  backbone  as  shown 
in  Figure  7.  This  allows  users  to  transfer  information  throughout  the  MOB,  and  to  reach 
long-haul  lines  not  homed  off  of  their  ITN.  [Ref.  8:p.  38]  Finally,  Figure  8  depicts  many 
MOB’s  interconnected.  This  provides  connectivity  throughout  the  theater,  and  into  the 


fixed  systems  via  Defense  Communications  System  (DCS)  gateways.  [Ref.  8:p.  42] 
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Figure  6:  Information  Transfer  Node  [Ref.  8:p.  38] 


Figure  7:  Interconnected  ITN’s  forming  a  MOB  [Ref.  8:p.  39] 
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Figure  8:  Theater-wide  Connectivity  [Ref.  8:p.  43] 

3.  Evolutionary  Path 

The  evolutionary  path  in  AFP  700-50  Vol.  II  is  a  restatement  of  previous 
ideas:  using  an  evolutionary  approach  to  integrating  commercially  available  standards, 
technologies,  and  concepts  into  the  DCSA.  The  rationale  is  simple:  fiscal  constraints 
will  not  allow  the  fielding  of  an  entirely  new  family  of  equipment.  Interfacing  existing 
systems  to  new  systems  (or  among  non-interoperable  current  systems)  will  be  both  a 
priority  and  challenge.  [Ref.  8:p.  46] 


30 


E.  SUMMARY 


The  consensus  from  the  high  level  joint  guidance  through  the  Air  Force  technical 
architecture  is  that  deployable  systems  must  be  able  to  support  the  warfighter.  Since 
solutions  are  needed  now,  and  money  is  hard  to  come  by,  interfaces  will  play  a  major  role 
in  this  evolution.  The  long  range  objective  is  to  incorporate  as  much  off-the-shelf 
equipment  and  technology  into  the  deployed  environment  as  possible.  This  should  ensure 
interoperability  among  users  within  the  theater,  and  between  the  fixed  environment  and 
deployed  systems. 
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IV.  DEPLOYABLE  SYSTEMS  AT  PRESENT 


This  chapter  provides  an  overview  of  the  deployable  equipment  presently  in  use, 
and  introduces  some  of  the  challenges  presented  to  those  systems  during  Operation  Desert 
Storm.  The  Tactical  Air  Control  System  (TACS)  and  combat  communications  provide  the 
bulk  of  what  is  generally  considered  deployable  or  tactical  communications.  Although 
their  missions  are  different,  much  of  their  supporting  communications  infrastructure  is  the 
same. 


A.  TACTICAL  AIR  CONTROL  SYSTEM 

The  TACS  is,  as  its  name  states,  a  system.  A  number  of  components  serve  to  pull 
the  entire  air  picture  together.  In  broad  terms,  the  TACS  has  two  primary  missions: 
control  and  monitor  the  movements  of  tactical  aircraft,  and  provide  the  means  for  request 
and  control  of  tactical  air  support  (also  known  as  close  air  or  ground  support).  Figure  9 
shows  the  overall  TACS  [Ref.  9:p.  32].  The  TACS  uses  the  principle  of  centralized 
control  and  decentralized  execution  in  both  structure  and  operation.  Its  focal  point  is  the 
Tactical  Air  Control  Center  (TACC). 

History  has  shown  the  absolute  necessity  for  centralized  control  and  dc  centralized 
execution  in  tactical  air  operations.  A  TACC  is  the  hub  of  that  activity.  A  TACC 
is  the  operational  facility  in  which  the  Air  Component  Commander  (ACC)  plans, 
directs,  and  controls  tactical  resources.  The  TACC  enables  the  ACC  and  his  senior 
staff  to  supervise  the  activities  of  assigned  or  attached  forces  and  to  monitor  the 
actions  of  both  enemy  and  friendly  forces.  [Ref.  10:p.  1] 
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Figure  9:  The  Tactical  Air  Control  System  [Ref.  9:p.  32] 

1.  The  Tactical  Air  Control  Center 

The  functions  of  the  TACC  are:  force  employment,  flight  management,  battle 
management,  and  systems  management.  Force  employment  is  the  result  of  the  Air 
Tasking  Order  (ATO)— the  translation  of  the  ACC’s  guidance  and  strategy  into 
coordinated  and  detailed  execution  orders.  Flight  management  monitors  the  progress  of 
assigned  missions.  Battle  management  is  control  of  actions  taken  in  direct  response  to 
those  of  enemy  forces,  while  systems  management  ensures  the  smooth  flow  of  C2 
information  between  the  various  elements  of  the  TACS.  [Ref.  I0:p.  IJ 
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In  the  joint  arena,  the  TACC  is  the  C2  system  that  supports  the  Air  Force 
Component  Commander/Commander  Air  Force  Forces  (AFCC/COMAFFOR)  for  airspace 
management.  It  is  dedicated  to  and  operationally  responsive  to  him  for  airspace  control, 
air  support  coordination  and  control,  and  air  strike  coordination  and  control. 
Decentralized  execution  of  air  missions  (the  ATO)  by  subordinate  elements  of  the  TACS 
promotes  mission  effectiveness  and  enhances  responsiveness.  [Ref.  1 1  :p.  4-24] 

The  combat  plans  division  of  the  TACC  develops  the  ATO  based  upon  mission 
objectives,  availability  of  forces,  and  the  tactical  situation.  It  tasks  units  to  accomplish 
specific  missions  in  support  of  the  commander’s  objectives,  and  contains  enough  detail 
to  enable  the  air  crews  and  TACS  elements  to  accomplish  those  missions.  [Ref.  10:p.  2] 
The  combat  operations  division  then  provides  centralized  control,  monitoring,  and 
supervision  of  the  decentralized  execution  of  the  ATO.  Flexibility  is  built  in  to  allow 
adjustment  to  the  ATO  should  the  tactical  situation  dictate.  [Ref.  10:p.  4] 

2.  Tactical  Control,  Monitoring,  and  Coordination 

The  TACS  uses  a  tiered  approach  to  assist  the  TACC  in  its  tasks  of 
controlling,  monitoring,  and  coordinating  tactical  aircraft  (and  then  reporting  their 
movements).  The  subordinate  elements  to  the  TACC  are  the  control  and  reporting  centers 
(CRC’s),  the  control  and  reporting  posts  (CRP’s),  the  forward  air  control  posts  (FACP’s), 
the  message  processing  center  (MPC),  and  the  airborne  warning  and  control  elements. 
[Ref.  9:p.  32] 


34 


cl  Control  and  Reporting  Center 

The  CRC  is  directly  subordinate  to  the  TACC  and  is  the  primary  element 
concerned  with  decentralized  execution  of  air  defense  and  air  space  control  operations. 
The  CRC  gets  its  tasking  and  receives  weapons  allocations  from  the  TACC.  Sensor  or 
radar  information  comes  to  it  from  ground-based  sources  (such  as  the  CRP’s  and  FACP’s) 
as  well  as  airborne  elements.  [Ref.  ll:p.  4-24] 

Within  its  area  of  responsibility,  the  CRC  directs  the  region  or  sector  air 
defense  and  provides  aircraft  control  and  monitoring  for  both  offensive  and  defensive 
missions.  It  relays,  as  directed,  mission  changes  to  aircraft  and  coordinates  control  of 
missions  with  subordinate  TACS  elements  and  other  agencies.  In  addition,  it  has  the 
following  responsibilities: 

•  Supervise  subordinate  radar  elements 

•  Provide  threat  warning  for  friendly  aircraft 

•  Ensure  air  defense  assets  of  all  services  are  employed  in  mutually  supporting  roles 

•  Coordinate  procedures  based  upon  friendly  artillery  fire  plans 

•  Establish  the  means  for  air  traffic  regulation  and  identification 

•  Support  air  rescue  operations  [Ref.  12:p.  4] 

b.  Control  and  Reporting  Post 

The  CRP  is  subordinate  to  the  CRC  and  provides  radar  surveillance  and 
aircraft  control  within  an  assigned  sector.  It  has  similar  capabilities  to  the  CRC  and  can 
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assume  CRC  functions  when  directed.  One  or  more  CRP’s  may  be  employed  depending 
upon  area  size,  terrain,  and  anticipated  level  of  threat  [Ref.  ll:p.  4-24] 

c.  Forward  Air  Control  Post 

The  FACP  is  the  mobile  radar  element  subordinate  to  the  CRC  or  CRP. 
It  is  normally  deployed  into  forward  areas  to  extend  radar  coverage  and  to  provide  control 
of  air  operations,  early  warning  surveillance,  and  gap  filler  service.  Because  of  its 
mobility  and  compact  design,  the  FACP  can  be  quickly  moved  to  maintain  a  desirable 
location  for  a  changing  tactical  situation.  During  initial  or  contingency  operations,  a 
FACP  may  be  the  only  ground  radar  available,  and  would  report  directly  to  the  TACC. 
[Ref.  12:p.  5] 

d.  Message  Processing  Center 

The  MPC  supports  the  TACC,  CRC’s,  and  CRP’s,  acting  as  the  interface 
control  unit  foi  the  TACS.  It  is  the  primary  element  of  the  TACS  that  provides  for  the 
automatic  exchange  of  data  with  other  services  and  air  defense  systems.  It  uses  the 
tactical  data  link  (TADEL)  to  "talk"  to  other  services,  and  provides  the  capability  to 
translate  from  one  TADIL  format  to  another.  This  last  feature  enhances  overall  service 
interoperability  since  at  least  two  formats  are  currently  in  use  between  the  three  military 
departments.  [Ref.  ll:p.  4-26] 

e.  Airborne  Warning  and  Control 

The  airborne  warning  and  control  system  (AWACS)  provides  an  airborne 
radar  platform  coupled  with  a  C2  capability.  This  enables  it  to  perform  the  function  of 
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a  CRC  or  CRP,  or  to  provide  enroute  C2  during  a  tactical  deployment  The  basic  mission 
responsibilities  include  surveillance,  warning,  control,  and  battle  management.  The 
AW  ACS  can  detect  initial  hostile  air  action  and  provide  its  radar  picture  to  ground  and 
naval  units  via  the  TADIL.  In  addition,  the  AW  ACS  can  monitor  surface  vessels  and 
provide  the  capability  to  monitor  enemy  naval  activity,  and  deny  them  the  advantage  of 
conducting  covert  operations  in  an  area  where  no  surface  radar  exists.  The  AWACS  can 
also  provide  information  on  friendly  ground  forces  through  the  use  of  transponders.  [Ref. 
12:p.  9] 

The  Joint  Surveillance  Target  Attack  Radar  System  (Joint  STARS)  aircraft 
is  not  shown  as  part  of  the  TACS  in  Figure  9  because  it  is  still  under  development,  but 
it  provides  a  look-down  radar  to  capture  the  area  beyond  the  forward  line  of  troops 
(FLOT).  It  has  a  moving  target  indicator  (MTI)  which  will  detect  vehicles  in  either  a 
broad  or  focused  mode,  and  a  synthetic  aperture  radar  which  can  provide  terrain  mapping 
or  coverage  for  fixed  targets.  [Ref.  13:p.  53] 

3.  Tactical  Air  Support  and  Control 

The  elements  that  assist  the  TACC  in  its  task  of  tactical  air  support  and  control 
functions  are  the  air  support  operations  center  (ASOC),  tactical  air  control  parties 
(TACP’s),  forward  air  controllers  (FAC’s),  the  wing  operations  center  (WOC),  and  the 
airborne  battlefield  command  and  control  center  (ABCCC).  [Ref.  9:p.  32] 
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a.  Air  Support  Operations  Center 

The  ASOC  is  collocated  with  the  senior  Army  tactical  operations  center. 
The  ASOC  plans,  coordinates,  and  directs  immediate  tactical  air  support  of  ground  forces. 
It  is  subordinate  to  the  TACC,  and  provides  fast  reaction  for  immediate  requests  for  close 
air  support,  tactical  air  reconnaissance,  and  in  some  situations,  tactical  airlift.  [Ref.  12:p. 
6] 

b.  Tactical  Air  Control  Parties 

TACP’s  are  subordinate  to  the  ASOC  and  are  located  at  each  appropriate 
command  echelon  of  the  supported  ground  force,  normally  battalion  through  corps.  They 
assist  the  commander  through  the  request  and  coordination  of  preplanned  and  immediate 
tactical  air  support.  [Ref.  12:p.  7] 

c.  Forward  Air  Control 

The  FAC’s  and  Airbome-FAC’s  (A-FAC’s)  are  subordinate  to  the 
TACP’s  and  primarily  dedicated  to  direct  support  of  friendly  ground  forces.  They  provide 
the  detailed  coordination  and  control  of  close  air  support  that  integrates  air-delivered 
firepower  with  friendly  ground  force  fire.  Although  the  FAC’s  primary  missions  are 
controlling  attacks,  requesting  air  support,  and  providing  immediate  battle  damage 
assessment,  the  A-FAC  also  performs  air  surveillance  and  search  and  rescue  operations 
as  needed.  [Ref.  12:p.  7] 
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<L  Wing  Operations  Center 

The  WOC  is  subordinate  to  the  TACC  and  serves  as  the  airwing 
commander’s  headquarters.  He  uses  the  WOC,  with  its  facilities  and  staff,  to  manage  and 
control  sortie  generation  by  his  wing.  [Ref.  9:p.  35] 

e.  Airborne  Command  and  Control  Center 

The  ABCCC  provides  flexibility  and  control  for  tactical  air  missions  and 
ensures  the  ATO  is  implemented.  It  normally  serves  as  an  extension  of  the  combat 
operations  division  of  the  TACC  or  as  an  airborne  ASOC.  The  facility  is  a  self-contained 
module  carried  aboard  a  specially  modified  C-130  aircraft  (a  number  of  external  antennas 
are  mounted  to  accommodate  the  C2  radios).  The  ABCCC  can  handle  only  procedural 
control;  it  cannot  perform  radar  coverage.  Radar  coverage  is  provided  by  the  AWACS. 
[Ref.  12:p.  8] 

B.  COMBAT  COMMUNICATIONS 

Where  the  TACS  has  a  mission  defined  in  terms  of  command  and  control,  combat 
communication’s  mission  is  to  provide  the  last  "C"  in  C3  to  facilitate  C2  in  the  deployed 
environment.  In  essence,  combat  communications  provides- the  backbone  or  infrastructure 
which  will  link  the  locations  together  within  a  theater,  and  even  across  theaters  as  needed 
[Ref.  14].  Figure  10  shows  an  overview  of  a  deployed  tactical  communications  network 
including  the  TACS  and  combat  communications  equipment.  The  elements  within  the 
TACS  were  explained  in  previous  sections. 
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Sit  APB  CODB: 


Combat  communications  provides  the  backbone  from  the  Air  Force  Component 
Headquarters  (AFCH)  to  the  tactical  air  bases  (TAB’s)  and  into  lite  Defense 
Communications  System  (DCS).  Where  the  TACS  relies  upon  mission-unique  equipment 
(radars  and  display  scopes,  for  example)  for  its  C2  mission,  it  uses  much  of  the  same 
equipment  as  combat  communications  for  its  links  between  sites.  These  links,  as  shown 
in  Figure  10,  are  usually  provided  by  the  joint  tactical  communications  (TRI-TAC)  and 
ground  mobile  forces  satellite  communications  (GMFSC)  equipment 

C.  TRI-TAC 

TRI-TAC  is  the  acronym  given  to  the  joint  tactical  communications  program  and 
the  equipment  procured  under  it.  The  program  evolved  out  of  interoperability  problems 
experienced  by  U.S.  forces  during  the  Korean  and  Viet  Nam  conflicts.  In  the  early  1960’s, 
the  U.S.  participated  in  an  allied  research  effort  with  Australia,  Canada,  and  the  United 
Kingdom  called  Mallard.  The  intent  was  to  develop  an  allied  communications  capability 
based  upon  evolving  digital  technologies.  In  1969,  the  Congress  mandated  that  the  U.S. 
pull  out  of  the  Mallard  effort  to  focus  upon  U.S.  joint-service  interoperability.  Even 
though  Mallard  never  provided  any  hardware,  it  did  generate  a  great  deal  of  technical 
information  which  would  serve  as  the  foundation  for  TRI-TAC.  [Ref.  16:p.  15] 

DoD  Directive  5148,  May  1971  created  the  TRI-TAC  program  and  office.  This 
program  was  intended  to  create  a  new  family  of  multi-service,  interoperable,  digital- 
switched  equipment  that  was  totally  compatible  across  the  family  and  with  existing 
equipment.  To  do  this,  common  equipment  items  were  divided  among  the  services,  who 
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acted  as  the  single  development  and  procurement  agent  for  that  item.  The  major 
objectives  of  the  TRI-TAC  program  according  to  the  DoD  charter  were: 

•  Achieve  the  necessary  degree  of  interoperability  among  tactical  communications 
systems  and  other  DoD  telecommunications  systems 

•  Place  in  the  field  in  a  timely  manner  new  tactical  communications  equipment 
required  by  the  armed  forces  to  perform  their  mission  and  which  reflected  the  most 
effective  technology 

•  Eliminate  duplication,  where  feasible,  in  the  development  of  service  equipment,  and 

•  Perform  the  above  in  the  most  economical  manner 

The  TRI-TAC  office,  specifically  the  director,  was  tasked  to  act  as  the  systems 
architect  and  principal  planner  for  the  TRI-TAC  system.  [Ref.  16:p.  16] 

The  equipment  procured  can  be  divided  into  six  general  categories:  user  terminals, 
switching  facilities,  control  element,  transmission  facilities,  multiplexers,  and  modems. 
By  the  late  1980’s  most  of  the  major  equipment  had  been  fielded,  and  many  pieces  have 
evolved  through  internal  equipment  and  software  updates.  Table  4  provides  the  description 
and  nomenclature  of  the  major  pieces  of  TRI-TAC  equipment  by  category.  The  multiplex 
and  modem  equipment  is  frequently  referred  to  as  digital  group  multiplex  (DGM) 
equipment.  The  AN/TSQ-146  Multiplex  Van  is  not  a  separate  piece  of  multiplex 
equipment,  but  rather  an  assemblage  of  DGM  equipment  into  a  larger  van  that  provides 
a  patching  and  testing  capability. 
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TABLE  4:  TRI-TAC  EQUIPMENT  [Adapted  from  Ref.  16:p.  20] 


TYPE 

DESCRIPTION 

NOMENCLATURE 

User  Terminals 

Digital  Subscriber  Voice  Terminal 

KY-68 

Digital  Nonsecure  Voice  Terminal 

TA-954/1042 

Advanced  Narrowband  Digital 

Voice  Terminal 

CV-3591 

Communications  Terminal 

AN/UGC-144 

Lightweight  Digital  Facsimile 

AN/UXC-7 

Switching  Facilities 

750  Line  Nodal  Circuit  Switch 

AN/TTC-39 

150  Line  Unit  Level  Circuit  Switch 

AN/TTC-42 

30  Line  Unit  Level  Circuit  Switch 

SB-3865 

50  Line  Store  and  Forward 

Message  Switch 

AN/TYC-39 

12  Line  Unit  Level  Message  Switch 

AN/GYC-7 

Control  Element 

Communications  Nodal  Control 
Element 

AN/TSQ-111 

Transmission  Facilities 

Troposcatter  Radio  Set 

AN/TRC-170 

Line-of-Sight  Radio  Terminal  Set 

AN/TRC-173 

Line-of-Sight  Radio  Repeater 

AN/TRC-174 

Tropo-satellite  Support  Radio 

RT-1492 

Fiber  Optic  Interface  Unit 

AN/TAC-1 

Multiplexers 

Multiplex  Van 

AN/TSQ-146 

Remote  Loop  Group  Multiplexer 

TD-1233 

Remote  Multiplexer  Combiner 

TD-1234 

Loop  Group  Multiplexer 

TD-1235 

Trunk  Group  Multiplexer 

TD-1236 

Master  Group  Multiplexer 

TD-1237 

Cable  Driver  Modems 

Group  Modem 

MD-1026 

Low  Speed  Cable  Driver  Modem 

MD-1023 

High  Speed  Cable  Driver  Modem 

MD-1024 

Remote  Loop  Group  Multiplexer 
Cable  Driver  Modem 

MD-1025 

Low  Speed  Pulse  Restorer 

TD-1218 

High  Speed  Pulse  Restorer 

TD-1219 
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A  word  about  equipment  packaging  is  in  order  here.  Terminals,  multiplexers,  and 
modems  are  usually  man-portable  devices,  ranging  in  size  from  a  desk  telephone  to  a 
desktop  personal  computer,  and  less  that  40  pounds.  Switching,  control,  and  transmission 
facilities  are  usually  integrated  into  their  own  shelters  which  require  the  use  of 
mobilization  equipment  and  trucks  to  move  them.  The  Air  Force  uses  the  S-280  and  S- 
250  shelters  for  this  equipment.  The  S-280  is  about  7’  x  T  x  14’  and  can  weigh  up  to 
10,000  pounds  when  fully  configured.  The  AN/TTC-39,  AN/TTC-42,  AN/TYC-39, 
AN/TSQ-111,  and  one  version  of  the  AN/TRC-170  use  the  S-280  shelter.  The  S-250 
shelter  is  sized  to  fit  in  the  bed  of  a  standard  pick-up  truck,  and  can  weight  up  to  6,000 
pounds  when  fully  configured.  The  trucks  that  carry  this  shelter  are  modified  to  handle 
the  extra  weight.  A  smaller  version  of  the  AN/TRC-170  uses  the  S-250  shelter. 

D.  GROUND  MOBILE  FORCES  SATELLITE  COMMUNICATIONS 

The  ground  mobile  forces  satellite  communications  (GMFSC)  terminals  are  not 
formally  part  of  the  TRI-TAC  program,  but  are  complementary  since  TRI-TAC  does  not 
include  any  satellite  communications  equipment  The  Air  Force  uses  two  GMFSC 
terminals,  the  AN/TSC-94A  and  the  AN/TSC-100A.  Both  use  super-high  frequency 
(SHF)  radios,  but  the  100A  is  a  larger,  multi-carrier  frequency  version  with  greater  built- 
in  redundancy.  The  lOOA’s  are  frequently  used  as  "hub"  stations,  with  the  94A’s  acting 
as  "spokes"  and  extending  the  network.  Two  antennas  are  available  for  use,  the  standard 
8-foot  dish  or  the  higher  gain  20-foot  dish.  The  GMFSC  terminals  use  the  same  shelters 
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as  does  TRI-TAC.  The  AN/TSC-100A  is  housed  in  an  S-280  shelter,  and  the  AN/TSC- 
94A  uses  the  S-250. 

Figures  1 1  to  14  show  representative  connectivity  diagrams  for  how  the  TRI-TAC 
and  GMFSC  equipments  are  used  to  support  the  tactical  air  base  (TAB)  and  air  force 
component  headquarters  (AFCH)  in  the  near-  and  far-term. 

E.  SHORTFALLS  AND  TRENDS  FROM  DESERT  STORM 

The  conflict  in  the  Middle  East  affords  an  opportunity  to  study  how  deployable 
systems  worked  under  operational  use,  as  well  as  a  chance  to  view  the  larger  management 
processes  that  occur  above  the  theater  level.  While  not  exhaustive,  four  areas  are  listed 
below. 

1.  Phasing  of  Equipment  Arrival 

With  an  initial  emphasis  on  getting  a  deterrent  presence  in  theater,  the 
communications  equipment  needed  to  eventually  manage  that  presence  was  considered 
a  low  priority  for  use  of  airlift  assets.  Only  after  discussions  among  senior  officers  to 
alert  commanders  that  they  would  not  be  able  to  control  their  forces  without  the 
supporting  communications  equipment  did  the  priorities  move  up.  But  it  was  still  several 
weeks  before  the  larger  pieces  of  equipment  arrived.  Although  the  Time  Phased  Force 
Deployment  List  (TPFDL)  is  intended  to  iron  out  these  details  in  advance,  allocation  of 
airlift  assets  was  conducted  on  an  ad  hoc  basis  and  was  complicated  by  the  non-modular, 
heavy  equipment  which  needed  to  be  transported.  [Ref.  17] 
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TAB  CURRENT  (1991) 
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Figure  13:  AFCH  Current  (1991)  [Ref.  15:p.  27] 
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2.  Strategic/Tactical  Interface 

This  area  has  been,  and  continues  to  be,  a  problem  when  deployed 
communications  equipment  attempts  to  interface  with  fixed  systems  such  as  the  DCS 
[Ref.  16:p.  28].  This  stems  from  the  different  environments  each  system  operates  within, 
and  the  standards  and  test  procedures  each  accordingly  employs.  In  fact,  of  the  24  trunks 
between  the  U.S.  and  the  Middle  East,  18  did  not  work  properly  until  21  Dec  90-four 
months  after  intended  activation.  [Ref.  18] 

3.  Satellite  Communication  Dependence 

The  network  established  for  Desert  Storm  relied  greatly  upon  satellite 
communication  (SATCOM)  for  its  success.  This  medium  provided  the  capability  to  grow 
and  reconfigure  under  dynamic  conditions  which  the  network  architects  desired.  [Ref. 
19:p.  42]  SATCOM  was  the  only  feasible  way  to  distribute  the  network  over  the  vast 
theater  of  operations  and  provide  the  connections  back  into  the  DCS.  Terrestrial 
communications  were  used  to  extend  the  network  further  from  "spoke"  sites  and  served 
to  provide  the  critical  redundancy  between  sites  already  connected  via  SATCOM.  [Ref. 
19:p.  43] 

4.  Paradigm  Shift  in  Operations 

The  current  command  structure  for  air  operations  places  most  of  the  command 
and  control  functions  physically  on  the  ground.  However,  during  Desert  Storm,  the  roles 
reversed  and  much  of  the  C2  of  air  operations  took  place  in  the  air.  The  primary 
platforms  involved  were  the  Airborne  Warning  and  Control  System  (AWACS),  the 
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Airborne  Command  and  Control  Center  (ABCCC),  the  Joint  Surveillance  and  Targeting 
Attack  System  (Joint  STARS),  and  Rivet  Joint  (a  signals  intelligence  aircraft).  This  is  a 
significant  departure  from  the  historical  command  and  control  role  for  aircraft  as  primarily 
sensors.  [Ref.  20]  This  evolution  in  operations  could  be  shifting  the  Air  Force  toward  a 
new  de  facto  C2  architecture  which  could  provide  unparalleled  capability,  but  will  also 
force  designers  to  deal  with  growing  complexities  and  associated  issues. 

F.  SUMMARY 

The  Tactical  Air  Control  System  and  combat  communications  comprise  the  majority 
of  what  the  Air  Force  calls  tactical  communications.  Both  systems  use  the  TRI-TAC  and 
GMFSC  equipment  to  provide  the  communications  links  needed  in  the  deployed 
environment:  TACS  for  the  airspace  management  and  control  missions,  and  combat 
communications  for  theater  connectivity.  Desert  Storm  presented  challenges  to  deployable 
systems  from  both  a  technical  and  conceptual  standpoint.  Not  only  was  the  actual 
equipment  put  to  the  test,  but  the  entire  process  of  providing  command  and  control  has 
been  opened  up  for  examination. 
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V.  CENTRAL  ISSUES  AND  CONCEPTS 


This  chapter  is  not  intended  to  "solve"  the  problems  currently  facing  communication 
systems  planners,  but  is  an  attempt  to  lay  out  a  selection  of  variables  for  consideration 
so  as  to  help  "define"  the  problem.  Due  to  the  interdependence  of  the  variables,  a 
systems  approach  was  considered  appropriate  as  an  analysis  method.  Every  attempt  was 
made  not  to  reduce  a  very  complex  problem  into  simple,  toy-problem  terms,  but  more 
into  chunks  that  illustrate  the  interdependence  of  the  elements. 


A.  DEFINITION  OF  C2 

At  the  core  of  any  military  communications  issue  should  be  the  reason  that 
communication  is  needed:  to  facilitate  and  support  command  and  control  (C2)  of  the 
forces  and  means  of  war.  JCS  Publication  1-02  provides  a  good  starting  point  for  C2 
from  which  to  build  upon. 

1.  JCS  Pub  1-02  Definition  of  C2 

The  exercise  of  authority  and  direction  by  a  properly  designated  commander  over 
assigned  forces  in  the  accomplishment  of  the  mission.  Command  and  control 
functions  are  performed  through  an  arrangement  of  personnel,  equipment, 
communications,  facilities,  and  procedures  employed  by  a  commander  in  planning, 
directing,  coordinating,  and  controlling  forces  and  operations  in  the  accomplishment 
of  the  mission.  [Ref.  21:p.  77] 

Perfect  C2  implies  some  level  of  omnipotence  on  the  part  of  the  commander, 
the  ability  to  have  all  the  desired  information  available  to  make  a  decision  at  the  time  of 
the  commander’s  choosing  (what  he  needs  to  know  when  he  needs  to  know  it). 
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2.  C2  is  Information  Centered 


Information,  as  opposed  to  raw  data,  is  what  allows  a  commander  to  make 
decisions  that  will  favorably  affect  the  outcome  of  war.  Paul  Stares  said  in  his  book 
Command  Performance: 

The  contribution  of  command  and  control  to  military  effectiveness  derives  from  the 
use  of  its  basic  commodity-information.  With  accurate  information,  uncertainty 
about  the  surrounding  environment  can  be  reduced  and  decisions  affecting  the 
readiness,  movement,  and  application  of  military  force  can  be  taken  with  a  clearer 
understanding  of  the  likely  costs  and  benefits.  If  processed  and  delivered  promptly, 
information  can  also  provide  more  time  for  these  decisions  to  be  taken  and, 
moreover,  implemented  with  successful  results.  [Ref.  22:p.  19] 

Decisions  made  without  the  benefit  of  information  are  at  best  lucky,  and  at 
worst  disastrous.  As  Stares  points  out,  to  be  of  any  value,  this  information  must  possess 
at  least  two  qualities:  timeliness  and  accuracy. 

3.  Timeliness  and  Accuracy 

Perfect  information  should,  by  implication,  possess  both  timeliness  and 
accuracy.  In  reality,  perfect  information  is  not  available  to  the  commander.  In  general, 
accuracy  and  timeliness  are  proportional,  where  highly  accurate  information  can  take  a 
very  long  time  to  prepare  and  confirm.  Under  dynamic  conditions,  this  situation  would 
not  prove  helpful.  As  such,  a  balance  between  the  two  qualities  is  desirable.  Some 
amount  of  accuracy  is  traded  off  to  allow  the  information  to  get  to  the  commander  in  time 
to  be  of  value.  Determining  how  "good"  is  "good  enough"  and  trying  to  quantify  the 
trade  off  between  timeliness  and  accuracy  is  beyond  the  scope  of  this  effort.  However, 
assignment  of  a  confidence  level  to  information  is  one  way  to  provide  an  indication  of 
how  sure  the  source  is  about  the  accuracy  of  the  information. 
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There  is  an  economic  concept  called  the  "Law  of  Diminishing  Marginal 
Returns"  where,  as  additional  resources  are  used,  the  incremental  increase  in  output 
declines  with  higher  levels  of  resource  usage.  Beyond  some  point,  there  is  zero  or 
negative  marginal  return  for  resources  used  in  the  production  an  output.  Using  the  above 
case  as  an  example,  it  may  be  possible  to  attain  a  90%  confidence  for  accuracy  of 
information  within  1  hour,  but  to  improve  the  confidence  an  additional  5-9  percentage 
points  (to  95-99%)  may  require  an  additional  4  hours.  Figure  15  illustrates  this  point  in 
graphic  form. 


Time 


Figure  15:  Confidence  in  Information  Curve 
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The  shape  of  the  curve  is  due  to  the  underlying  technologies  and  processes 
/hich  are  used  to  obtain  and  confirm  the  information.  A  relatively  fast  sensor  may 
indicate  the  occurrence  of  an  event  within  a  class  of  events,  while  different  sources  may 
be  consulted  to  further  narrow  the  event.  All  of  this  confirmation  takes  time,  especially 
where  manual  intervention  is  needed.  For  many  applications,  the  90%  confidence  may 
be  sufficient  to  base  decisions  upon.  Policy,  sensitivity  of  decisions,  and  commander’s 
experience  will  likely  shape  the  thresholds  used  in  practice. 

What  this  information  allows  a  commander  to  do  is  outperform  the  opponent 
in  real-time  under  dynamic  conditions.  Colonel  John  Boyd  illustrated  this  concept  well 
in  what  is  called  the  "O-O-D-A"  loop. 

4.  Boyd’s  O-O-D-A  Loop 

Colonel  Boyd,  a  former  USAF  pilot  and  aerial  combat  theorist,  developed  this 
model  originally  for  maneuver  warfare.  It  is  used  here  to  simplify  and  illustrate  the  C2 
process.  According  to  James  Fallows: 

This  ’loop’  consists  of  cycles  of  observing  (O)  the  enemy’s  actions,  orienting  (O) 
oneself  to  the  unfolding  situation  deciding  (D)  on  a  counter,  and  then  acting  (A). 
The  principle  is  that  the  side  which  can  complete  these  cycles  more  quickly  will 
ultimately  prevail  ....  [Ref.  23:p.  19] 

As  seen  in  Figure  16,  Boyd’s  model  does  not  show  the  adversary’s  O-O-D-A 
loop  and  the  environment  that  contains  both.  Dr.  Joel  Lawson  and  Prof.  Paul  Moose 
extended  and  adapted  Boyd’s  model  to  include  the  adversary’s  loop  in  the  overall 
environment,  as  seen  in  Figure  17  [Ref.  24:p.  187].  Although  different  terms  are  used, 
the  functions  remain  essentially  the  same. 
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Figure  16:  Boyd’s  O-O-D-A  Loop 
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The  balance  of  this  chapter  is  concerned  with  the  issues  and  concepts  that 
form  the  basis  for  designing  architectures  and  systems.  Just  as  the  Chief  of  Staff  of  the 
Air  Force  (CSAF)  asked  his  staff:  "...how  would  we  set  up  comms  for  a  Desert  Storm 
like  operation  if  we  were  free  to  do  it  the  way  we  want,  starting  from  a  clean  sheet  of 
paper?"  we  can  also  build  from  the  ground  up.  [Ref.  15:p.  31] 

B.  POLICY  AND  ASSUMPTIONS 

We  cannot  truly  start  with  a  blank  sheet  of  paper.  The  role  of  policy  is  to  provide 
the  planning  guidance  needed  to  shape  and  narrow  the  feasible  alternatives.  Viewed  in 
terms  of  operations  analysis,  policy  helps  define  the  objective  function  and  constraints 
used  to  obtain  an  optimal  solution  to  a  problem.  For  example,  the  problem  might  state: 

Minimize:  Cost 

Subject  To:  Capability  >  X 

Airlift  Requirements  <  Y 

Personnel  Requirements  <  Z 

Or  the  problem  could  be  of  the  form: 

Maximize:  Capability 

Subject  To:  Cost  <  S 

Airlift  Requirements  <  Y 

Personnel  Requirements  <  Z 

The  above  illustrates  different  ways  to  state  the  problem.  The  bottom  line  is  to 
provide  an  acceptable  level  of  capability  for  a  specified  number  of  dollars.  (It  should  be 
noted  that  the  problem  as  stated  may  or  may  not  have  a  feasible  solution).  The  difficulty 
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arises  in  trying  to  write  a  model  which  will  allow  an  analytical  solution.  Many  variables 
will  of  necessity  be  constrained,  i.e.,  money  that  can  be  allotted  or  current  airlift  available. 
However,  by  holding  the  other  values  constant  and  letting  the  variable  of  interest  run 
unconstrained,  the  model  can  return  a  value  that  will  satisfy  the  constraints  as  written. 
While  the  chosen  level  of  capability  may  require  three  times  the  gross  national  product 
or  more  airlift  than  currendy  exists  in  the  world,  this  can  still  be  used  as  a  planning  tool 
for  model  refinement  or  to  examine  the  underlying  technologies  with  greater  scrutiny. 

Given  that  previous  studies  and  guidance  are  leading  towards  smaller,  lighter,  more 
modular  equipment,  and  greater  interoperability  between  services  and  the  commercial 
sector,  what  issues  and  approaches  will  shape  an  integrated  transition  into  the  next 
century?  Due  to  the  complexity  of  C2  systems  (organizationally,  technically,  or  the 
human  element  involved)  it  may  never  be  possible  to  enumerate  a  "best"  solution  to  C2 
needs.  However,  through  an  illustration  of  the  trade-offs  involved  in  differing  approaches 
to  solving  parts  of  the  system,  it  may  be  possible  to  choose  a  better  system  than  if  no 
analysis  were  performed.  Because  the  initial  assumptions  or  conditions  have  such  a  great 
impact  upon  the  direction  the  system  planning  will  take,  it  is  helpful  to  review  some  of 
the  current  high  level  guidance. 

1.  Joint  Publication  1 

If  planners  are  to  design  systems  to  perform  in  a  wartime  environment,  they 
must  know  what  the  expected  environment  will  be.  However,  inconsistencies  exist 
between  high-level  documents,  and  even  within  documents.  Joint  Publication  1  states: 
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...the  arena  of  our  potential  operations  is  the  entire  planet,  with  its  surrounding 
aerospace,  from  the  ocean  depths  to  geosynchronous  orbit  and  beyond.  We  must 
be  prepared  to  defend  our  national  interests  in  every  type  of  terrain  and  state  of  sea 
and  air,  from  jungles,  deserts,  and  tropical  seas  to  polar  ice  caps.  The  US  Armed 
Forces  face  the  challenge  of  mastering  multifaceted  conditions,  unlike  nations 
whose  military  forces  can  concentrate  on  a  more  limited  range  of  environments. 
Indeed,  the  ability  to  project  and  sustain  the  entire  range  of  military  power  over  vast 
distances  is  a  basic  requirement  for  the  US  Armed  Forces  and  contributes,  day  in 
and  day  out,  to  the  maintenance  of  stability  and  deterrence  worldwide.  [Ref.  25:p. 
2] 


In  contrast,  the  planning  emphasis  appears  to  be  shifting  toward  the  crisis  and 
limited  objective  warfare  (CALOW)  environment  in  the  Copernicus  architectural 
document,  as  shown  in  Figure  18.  As  will  be  seen  next,  the  C2  Functional  Analysis  and 
Consolidation  Review  Panel  (FACRP)  states  we  should  plan  for  general  nuclear  war  and 
focus  attention  on  the  CALOW  environment  Any  system  designed  without  a  clear 
vision  of  its  intended  use  will  likely  be  compromised  in  some  way. 


\ 


|  Peace |  1  Crisis  |  |  Regional  Conflict  1  [Global  War| 
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Figure  18:  Operational  Continuum  (1990- Beyond)  [Ref.  26:p.  2-4J 
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2.  FACRP 


With  a  goal  of  finding  more  efficient  ways  to  meet  the  mission,  the  FACRP 
reviewed  national  strategy  and  policy  to  assess  C2  operational  requirements  in  support  of 
the  National  Command  Authorities  (NCA)  and  Commanders  in  Chief  (CINCs).  Their 
purpose  was  to  "...identify  cost-effective  approaches  to  satisfying  DoD-wide  C2 
requirements,  specifically  through  consolidation  of  capabilities  where  such  action  makes 
operational  and  economic  sense."  [Ref.  27 :p.  2]  The  FACRP  went  on  to  list  the  economic 
and  strategy  changes,  and  the  C2  drivers  which  will  shape  and  impact  future  architectures. 
These  lists  are  shown  in  Tables  5  and  6.  They  also  found  that  the  current  DoD  C2 
structure  would  not  provide  the  long-term  efficiencies  needed,  and  suggested  a  new  C2 
structure  would  have  the  features  below: 

•  A  consolidated,  DoD-wide,  global  C2  infrastructure 

•  A  greater  emphasis  on  joint  task  forces  as  the  principle  tactical  operational  forces 

•  Centrally  managed  operational  support  [Ref.  27  :p.  13] 

Even  though  much  of  the  above  information  is  consistent  with  the  findings 
from  the  studies  reviewed  in  Chapter  II,  consistency  of  policy  or  planning  guidance  is  still 
a  problem. 
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TABLE  5:  ENVIRONMENT  AND  STRATEGY  CHANGES  [Ref.  27:p.  3] 


Resource  Availability 

-  US  budget  constraints 

-  Decreasing  motivation  to  fund  at  Cold  War  levels 

-  Decreasing  defense  funding  advocacy  among  major  allies 

The  Soviet  Threat 

-  Continuing,  improving  strategic  forces 

-  Reduced  conventional  threat  to  Europe,  reduced  power  projection  capability 

-  Soviet  political  uncertainties 

The  Increased  Regional  Threat(s) 

-  Political  and  economic  power  shifts 

-  Insurgency,  drugs,  terrorism  problems 

-  Availability,  use  of  advanced  weapons,  including  weapons  of  mass 
destruction 

Strategy  Changes,  Force  Posture 

-  Forward  presence,  but  with  reduced  forces  at  fewer  overseas  bases 

-  Backed  up  by  CONUS  contingency  and  reserve  forces 

-  Planned  mobilization,  if  needed 

Technology  Advances 

-  High-lethality  weapons  (e.g.,  precision  guided,  chemical,  biological) 

-  High-capability  weapon  delivery  (missile  and  airborne)  systems 

-  Increased  use  of  space 

-  New  information  transmission,  processing,  support  capabilities 
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TABLE  6:  C2  DRIVERS  [Ref.  27:p.  7] 


Streamlining  and  Consolidating 

-  Reduce  C2  personnel 

-  Consolidate  U  &  S  organization  elements 

-  Eliminate  redundant  systems  where  possible 

Risk  Management  and  Acceptance 

-  Maintain  deterrence,  prepare  for  nuclear  war 

-  Determine  size,  nature,  and  location  of  forces 

-  Determine  minimum  essential  capabilities 

-  Standby  contingency  capabilities 

-  Mobilize  if  necessary 

Strategic  Agility 

-  Focus  on  low  end  of  the  conflict  spectrum 

-  Deter,  fight  regional  powers  if  necessary 

-  Support  forward-deployed  forces 

-  Support  rapid  deployment  and  redeployment 

-  Interact  and  interoperate  with  allies 

Force  C2  Interoperability 

-  Technical  standards  and  protocols 

-  Applications:  processing,  interpretation 

-  Procedures 

-  Command  response,  common  understanding 

Force  and  C2  Modularity 

-  Joint  and  combined  interoperability 

-  Relocatable/mobile  modular  assets 

-  Building-block  planning  tools 

Technology 

-  Networking 

-  Multilevel  security 

-  Automation,  communications 

-  New  sensing  and  reporting  systems 
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3.  The  Next  Step 

As  stated  earlier,  because  the  initial  assumptions  or  conditions  have  such  a 
great  impact  on  the  direction  system  planning  takes,  they  should  be  clear  and  consistent. 
This  forms  the  basis  of  the  "givens"  from  which  future  trade-off  analysis  can  occur. 

C.  PLANNING  AND  DESIGN  CONSIDERATIONS 

Chapter  II  reviewed  three  studies  which  laid  out  a  general  direction  of  smaller, 
lighter,  more  modular  and  interoperable  equipment  as  goals  for  any  new  deployable  TBM 
equipment  the  USAF  might  purchase.  In  addition,  C*I  for  the  Warrior  mentions  a  goal 
architecture  where  all  systems  are  connected  to  an  ether.  While  either  concept  is  not  hard 
to  visualize  as  a  possibility  in  its  end  form,  no  roadmap  exists  to  join  what  is  currently 
in  the  inventories  with  the  goal  architectures.  Many  factors  may  make  it  difficult,  but  not 
impossible,  to  realize  these  goals.  The  resolution  of  the  areas  explored  below  are 
considered  essential  by  the  author  for  a  cohesive  deployable  architecture  to  emerge. 

1.  Type  of  Conflict 

It  is  not  clear  from  policy  exactly  what  type  of  warfare  the  military  services 
should  realistically  prepare  for.  The  conflict  spectrum  presented  from  Copernicus  implies 
a  planning  shift,  as  does  the  FACRP.  Planning  should  be  consistent  with  the  probability 
of  occurrence,  but  must  also  factor  in  the  "cost"  of  being  unprepared,  even  for  some 
unlikely  event.  Since  the  needs  of  each  type  of  event  will  be  different,  the  broader  the 
range  covered  (on  the  spectrum),  the  greater  the  compromise  in  capability  for  each 
particular  application. 
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2.  Modularity 

Modularity  affords  greater  flexibility  in  terms  of  response  and  capability  sizing 
at  the  initial  stages  of  a  deployment  These  modules  should  be  compact  and  able  to  be 
configured  to  meet  the  needs  of  a  contingency  force.  Over  time,  however,  if  the  network 
becomes  large,  the  advantages  of  the  modules  could  diminish  (due  to  economies  of  scale) 
but  could  still  be  viable  if  the  network  is  somewhat  dynamic. 

How  modular  to  be  is  also  a  question,  since  many  functions  will  still  require 
specialized  equipment.  For  example,  a  telephone  switch  and  a  radar  are  very  different 
functions  and  would  likely  require  different  classes  of  equipment.  The  family  of  modules 
as  well  as  what  is  expected  of  them  must  be  considered  carefully. 

3.  Statement  of  Requirements 

Before  a  communications  structure  can  be  developed,  requirements  must  be 
determined.  As  a  result  of  post-Desert  Storm  tasking,  the  USAF  (as  well  as  JIEO  and 
other  organizations)  have  drafted  architectures  which  now  serve  as  the  design  model  for 
developing  the  supporting  communications  structure  [Ref.  28].  These  architectures  are 
helpful  in  showing  which  activities  are  coupled  and  which  are  not,  but  do  not  show  the 
relative  capacity  that  would  be  required  between  entities. 
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4.  Sizing  Requirements 

The  capacity  requirements  of  the  links  that  connect  the  various  entities,  as  well 

as  the  direction  of  flow  (A  to  B,  B  to  A,  or  both)  are  needed  to  properly  size  the  network. 

The  USAFTC  study  had  this  to  say  about  sizing: 

While  communications  connectivity  requirements  are  understood  (i.e.,  who  needs 
to  talk  to  whom)  the  expected  utilization  or  circuit  loading  is  not  well  characterized. 
Without  this  data,  the  degree  to  which  circuits  can  be  shared  in  a  demand 
assignment  or  packet  switching  environment  cannot  be  assessed.  [Ref.  4:p.  9] 

To  illustrate  this,  the  Air  Force  Communications  Command’s  Standard  Systems 
Center  eventually  provided  a  deployed  data  network  (in  support  of  Desert  Storm)  capable 
of  handling  in  excess  of  200,000  supply  and  maintenance  transactions  from  50  sites  each 
day-linked  back  to  a  host  computer  at  Langley  AFB,VA  by  commercial  satellite  links  at 
over  3  million  bits  per  second  (MBPS).  But  the  planning  for  this  network  did  not  get  off 
the  ground  until  the  first  planes  were  on  their  way  to  Saudi  Arabia.  While  the  concepts 
had  been  explored  earlier,  testing  was  being  accomplished  to  validate  it  during  the  build¬ 
up  of  forces.  Even  after  the  network  was  installed  and  became  operational,  it  continued 
to  grow  as  demands  increased.  [Ref.  29:p.  58]  This  situation  is  likely  to  be  the  norm  in 
the  future,  especially  as  data  networks  are  increasingly  used  to  support  the  warfighters. 

Understanding  what  needs  to  flow  between  entities  will  help  quantify  the  size 
of  the  links  needed.  Not  all  information  needs  to  go  in  every  direction.  Copernicus  uses 
the  ideas  of  "push-pull"  to  show  this.  "Push"  could  be  information  which  is  broadcast 
from  a  central  source  (such  as  intelligence  information  from  national  assets),  while  "pull" 
would  be  queries  or  requests  made  for  information  from  a  central  database.  In  the  "pull" 
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mode,  the  user  only  draws  in  the  information  of  immediate  interest.  [Ref.  26:p.  2-8]  Of 
course,  actually  determining  the  size  of  these  links  will  be  dependent  upon  the  service 
increment  chosen  as  the  basic  building  block.  This  is  one  of  the  roles  that  standards  play. 

5.  Standards 

Standards  provide  a  common  reference  point  for  determining  required  capacity 
of  service  (how  many  channels  of  a  given  size),  and  they  define  the  technical  parameters 
that  equipment  must  conform  to  in  order  to  connect  to  the  network.  While  deployable 
systems  use  a  digital  channel  based  upon  a  16  or  32  kilobit  per  second  (KBPS)  rate  and 
the  continuously  variable  sloped  delta  (CVSD)  voice  modulation  scheme  [Ref.  16:p.  19], 
modem  fixed  systems  use  a  64  KBPS  rate  and  the  pulse  code  modulation  scheme, 
commonly  called  a  DS-0  channel.  The  DS-0  channel  is  part  of  the  larger  North  American 
Multiplexing  Scheme  which  includes  DS-1  and  DS-3  (also  referred  to  as  T-l  and  T-3)  at 
1.544  and  44.736  MBPS.  [Ref.  30:p.  39]  Adopting  these  standards  would  ease  the 
strategic/tactical  interface  problem  highlighted  in  Chapter  IV,  and  allow  the  use  of  modem 
and  highly  reliable  commercial  equipment.  This  would  also  afford  deployed  users  the 
same  level  of  service  they  now  enjoy  in-garrison.  In  fact,  T-l  service  to  the  customer 
premises  is  now  common,  and  T-3  services  are  appearing  rapidly  as  more  tariffs  are 
approved  [Ref.  3  rip.  82].  The  down  side  is  an  initial  investment  in  new  equipment,  but 
this  has  in  recent  years  become  relatively  inexpensive  as  commercial  standards  and 
technology  have  outpaced  military  ones. 
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6.  Transportation  and  Phasing  of  Equipment 


More  modular  equipment  should  be  easier  to  move  (less  air  cargo  space 
required)  at  the  onset  of  hostilities  since  only  the  required  capabilities  need  to  be  sent. 
Recall  from  Chapter  II  that  the  initial  emphasis  for  Desert  Storm  was  on  getting  firepower 
into  theater,  not  necessarily  support  equipment.  Under  the  current  methods, 
communications  support  for  an  airwing  is  provided  from  organizations  outside  the  wing. 
While  this  works  well  for  sustainment,  it  is  not  responsive  to  rapid  deployment  needs  or 
contingencies.  As  such.  Tactical  Air  Command  (TAC)  is  exploring  a  wing-integral 
communications  concept  that  will  deploy  with  the  wing  and  provide  all  essential 
communications  for  the  first  two  weeks.  After  that,  the  sustaining  equipment  and 
personnel  would  assume  the  communications  functions.  [Ref.  29:p.  57] 

While  this  approach  could  help  alleviate  some  of  the  phasing  problems  that 
arose  during  Desert  Storm,  new  issues  are  brought  forth.  If  different  people  and 
equipment  will  be  responsible  for  the  same  support,  but  at  different  times,  how  will  the 
handoff  be  accomplished?  If  the  initial  package  becomes  part  of  the  sustaining  force,  it 
must  be  interoperable  and  compatible  with  it.  Modular  design  would  help  ensure  the 
follow  on  forces  would  be  able  to  add  to  the  capability  gracefully.  If  equipment  will  be 
"swapped  out,"  the  network  must  be  designed  in  such  a  way  as  to  ensure  an  orderly 
transition  with  little  or  no  outage  time. 

7.  Dispersal  and  Distributed  Processing 

Dispersal  and  distributed  processing  appears  as  a  goal  in  many  architectural 
documents  (recall  TC2-21  and  the  Air  Force  C-CS  Architecture,  for  example).  This 
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concept  spreads  equipment  and  personnel  over  a  greater  geographic  region  to  provide  a 
high  degree  of  physical  protection  to  both.  Embedded  in  this  concept  is  a  very  high 
degree  of  interoperability  and  conformance  to  standards.  Demands  on  the  network 
infrastructure  would  increase  since  each  dispersed  location  must  have  a  connection  into 
the  network.  But  it  may  be  possible  to  reduce  or  eliminate  some  of  the  transportation 
requirements  through  pre-positioning.  In  a  position  paper  on  tactical  C3!  architectures  in 
support  of  Global  Reach,  Captain  Duncan  McKenzie  advocates  the  construction  of  three 
Global  Reach  ground  entry  stations;  one  on  each  coast  of  the  United  States,  and  one 
within  the  footprint  of  the  Indian  Ocean  satellite  [Ref.  32:p.  1].  McKenzie’s  premise  is 
that  these  ground  stations  could  handle  the  "hubbing"  function  normally  assigned  to 
theater  assets,  so  that  the  equipment  actually  deployed  could  be  in  direct  support  of  a 
wing  [Ref.  32:p.  7]. 

This  is  a  departure  from  a  traditional  hierarchical  approach  to  C2,  which  he 
says  works  well  for  ground  forces,  but  not  for  air  forces  (as  they  found  out  during  Desert 
Storm).  He  attributes  this  to  differences  for  ground  and  air  forces  in  their  C2,  intelligence, 
and  logistics  relationships.  [Ref.  32:p.  2]  Where  ground  forces  are  very  hierarchical  in 
structure,  air  forces  tend  to  be  more  horizontal  (at  least  for  the  support  functions-the  C2 
functions  performed  by  the  TACC  would  still  remain  hierarchical  to  retain  centralized 
control).  Wings  deploy  to  a  tactical  air  base,  but  get  nearly  all  their  support  from  outside 
the  theater.  McKenzie  points  out  that  only  two  C2  circuits  originate  inside  the  theater, 
scramble  (used  to  "scramble"  alert  aircraft  toward  targets)  and  CAFMS  (computer  assisted 
force  management  system,  used  to  disseminate  the  ATO).  Supply  and  maintenance 
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functions  are  remoted  from  U.S.  bases,  and  intelligence  and  weather  go  direct  to  the  wing 
via  national  sources.  [Ref.  32:p.  3]  He  further  asks.  "Since  the  above  services  require 
little  or  no  intervention  by  higher  echelons  within  a  theater,  why  not  adopt  a  tactical 
network  architecture  that  simultaneously  provides  intra-theater  C2  connectivity  and  direct 
inter-theater  connectivity  between  deployed  air  forces  and  their  CONUS  based  sources?" 
[Ref.  32:p.  4]  His  concept  would  be  to  provide  the  ground  stations  with  connections  to 
networks  for  national  information,  trunks  to  other  ground  stations  for  inter-theater 
capabilities,  and  switching  facilities  for  intra-theater  needs.  A  user  would  reach  the 
ground  station  by  satellite,  and  would  be  patched  to  the  path  their  needs  dictate.  Figure 
19  shows  an  example  layout  for  a  ground  station.  Note  that  users  can  be  patched  direct 
to  another  user  (a  dedicated  path),  or  switched,  and  can  be  routed  within  the  theater,  or 
into  any  of  the  global  networks  that  the  ground  station  can  access. 

D.  SUMMARY 

There  are  a  great  many  issues  which  must  be  considered  if  an  integrated  approach 
to  providing  deployable  communications  is  to  be  taken.  In  some  ways,  the  way  in  which 
the  services  are  being  provided  is  evolving  faster  that  the  present  structure  can 
accommodate.  Some  issues  focus  on  the  technical  aspects  of  getting  equipment  to  talk 
to  and  understand  each  other,  while  others  are  more  related  to  planning  considerations, 
while  others  still  examine  the  more  fundamental  question  of  how  services  will  be 
provided.  All  are  import,  t  if  balance  and  perspective  are  to  be  maintained. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

There  has  been  a  great  deal  of  effort  at  many  levels  to  get  a  handle  on  the  problems 
that  face  deployable  systems.  These  efforts  should  be  acknowledged  for  their  attempts 
to  quantify  the  problems  and  develop  solutions  prior  to  any  of  this  author’s  own 
recommendations.  Specifically,  the  studies  reviewed,  the  after-action  reports  that  followed 
Desert  Storm,  0*1  for  the  Warrior,  and  the  Functional  Analysis  Consolidation  Review 
Panel  (FACRP)  all  demonstrate  that  the  technical  problems  are  reasonably  well 
understood  and  are  solvable.  The  people  behind  these  efforts  are  doing  their  best  to  take 
a  very  complex  situation,  one  which  crosses  many  functional  boundaries,  and  meld  it  into 
a  synthesized,  cohesive  whole.  Their  work  has  paved  the  way  for  better  communications 
support  for  the  warriors  in  the  future. 

Defining  the  goal  and  reaching  it  can  be  two  different  things,  however.  Where  it 
appears  the  technical  solutions  are  within  reach,  the  mechanisms  to  implement  those 
solutions  may  be  cumbersome,  or  worse  yet,  non-existent.  Integrated  problem  solving 
should  include  not  only  the  technical  solutions  but  also  the  addressing  of  the  means  to 
implement  those  solutions.  The  recommendations  below  serve  as  a  starting  point  for 
getting  some  of  these  areas  identified,  and  ultimately  solved. 
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B.  RECOMMENDATIONS 


1.  Assignment  of  Responsibility  and  Authority 

Assignment  of  responsibility  and  authority  has  yet  to  be  vested  in  a  single 
focal  point.  The  TBM  study  called  for  the  creation  of  a  "center  of  excellence"  where 
architectural  and  technical  expertise,  as  well  as  information  on  the  TBM  activities  of  other 
services,  could  be  centrally  located.  [Ref.  3:p.  5]  Although  a  General  Officer  Steering 
Group  (GOSG)  and  working  group  have  been  established  for  TBM  activities,  these  groups 
meet  only  periodically  to  resolve  issues  of  concern  and  to  set  broad  policy.  Their  charter 
is  included  as  an  Appendix  for  information  purposes. 

It  is  possible  that  the  GOSG  could  act  as  a  "board  of  directors"  in  guiding  the  TBM 
activities  for  the  Air  Force.  However,  it  is  not  clear  who  the  members  of  the 
"communications  corporation"  really  are,  what  their  responsibilities  would  be,  and  what 
the  relationships  between  them  would  be.  Following  the  lead  set  by  DISA,  focal  points 
should  be  established  for  areas  under  the  TBM  umbrella.  All  of  these  would  then  report 
back  to  the  TBM  architect  who  would  ensure  overall  harmony  of  effort.  The  TBM 
architect  should  also  act  as  the  Air  Force  focal  point  for  joint  activities  regarding 
deployable  communications. 

Without  a  center  of  excellence  to  guide  and  shape  the  efforts  of  many 
agencies,  the  Air  Force  lacks  the  integration  needed  to  ensure  the  findings  of  the  studies 
are  resolved.  Research  for  this  thesis  revealed  that  many  entities  are  developing 
independent  architectures  outside  any  broad  umbrella  structure  which  might  require  them 
to  fit  within  [Ref.  33:p.  1J.  On  the  bright  side,  actions  are  being  taken  by  the  new 
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architecture  and  integration  division  of  the  Joint  Staff  and  the  Office  of  the  Secretary  of 
Defense  to  eliminate  duplication  of  effort  and  get  control  of  greater  than  300  architectures 
[Ref.  34:p.  1], 

Where  to  place  such  a  center  and  how  to  staff  it  are  tough  issues.  Since  the 
best  operational  perspective  comes  from  people  immersed  in  the  operational  environment, 
it  may  be  possible  to  distribute  the  "center"  geographically  to  gain  expertise,  while  a  core 
group  would  be  responsible  for  the  day-to-day  management  of  affairs.  The  core  group 
would  manage  the  databases  and  coordination  with  other  services  and  DoD  agencies,  and 
the  designated,  distributed  focal  points  would  be  consulted  and  kept  apprised  through 
messages.  For  this  system  to  work  would  require  commitment  on  the  part  of  the 
distributed  representatives,  and  significant  dialogue  between  them  and  the  core  group. 
The  core  group  could  be  co-located  with  the  Technology  Integration  Center,  but  to  have 
any  power,  it  must  have  the  backing  of  Headquarters  and  the  major  commands 
(MAJCOM’s)  to  carry  out  its  mission.  The  expertise  is  available;  it  merely  needs  to  be 
assembled  and  oriented  toward  the  goal. 

2.  Follow-up  Mechanism 

Possibly  at  the  heart  of  the  above  problems  is  the  lack  of  any  institutionalized 
follow-up  procedures.  The  studies  did  not  carry  any  directive  authority  to  implement  their 
recommendations,  and  the  AFSB  does  not  track  the  status  of  a  study  once  completed  [Ref. 
35].  Nor  does  the  sponsor.  Air  Force  Systems  Command  (AFSC),  have  a  means  yet  to 
determine  the  status  of  corrective  actions  taken.  Although  measures  are  being 
implemented  informally  at  AFSC,  follow-up  action  will  still  be  sporadic  for  some  time 
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to  come.  [Ref.  36]  One  responsibility  of  the  TBM  architect  should  be  to  gauge  progress 
of  the  current  system  relative  to  the  goals  set  forth  from  sanctioned  studies. 

3.  Providing  the  Tools 
«.  Policy 

Above  all,  clear  policy  is  needed  to  guide  the  thinking  of  systems 
architects  and  engineers.  The  USAF’s  Global  Reach,  Global  Power  concept,  where  we 
desire  the  ability  to  respond  quickly  to  any  contingency,  at  any  point  on  the  earth,  helps 
frame  the  problems  to  be  solved.  But  this  broad  goal  will  be  difficult  to  reach  without 
breaking  it  into  smaller  pieces.  It  is  still  possible  to  respond  to  the  challenges  with  a 
balanced  suite  of  capabilities,  where  elements  of  the  suite  can  be  individually  tailored  to 
an  appropriate  mission.  Policy  should  help  determine  the  level  of  resources  to  use  in 
realizing  each  element  (based  upon  the  threat  and  its  probability  of  occurrence). 

b.  Models 

Modelling  and  computer  simulations  can  be  valuable  tools  when 
resources  are  tight  and  risks  are  high.  They  allow  many  options  to  be  examined  without 
ever  having  to  build  a  physical  system.  But  to  build  these  models  and  simulations 
requires  good  input  data  if  reasonable  results  are  to  be  expected.  The  Air  Force  has  very 
little  quantitative  knowledge  on  network  loading  under  stress  [Ref.  4:p.  8].  Traffic 
analysis  records  from  Desert  Storm  should  prove  helpful  in  developing  realistic  models 
for  wartime  communications  requirements.  However,  caution  should  be  exercised  since 
the  requirements  may  not  be  representative  or  scalable  to  other  situations.  An 
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understanding  of  the  model  will  be  critical  to  allow  its  evolution  and  growth  as 
requirements  and  future  needs  dictate.  This  understanding  will  hopefully  enable 
successful  alterations,  and  provide  greater  confidence  in  the  results  of  "what-if  ’  analysis. 
These  models  would  also  be  able  to  assist  in  trade-off  analysis  to  highlight  performance 
under  various  scenarios  for  the  alternatives  under  study. 

c.  Trade-off  Analysis 

Within  broad  guidelines,  many  different  architectures  or  systems  would 
be  equally  capable  of  providing  suitable  service.  While  this  is  understood  and  exploited 
in  weapon  systems  design,  it  seems  to  be  a  relatively  new  concept  to  tactical  C2  or  TBM. 
A  report  by  the  E-Systems  Corporation,  conducted  for  the  Electronics  Systems  Division 
of  AFSC  did  attempt  to  determine  the  relative  merits  of  a  fully  centralized  versus  fully 
distributed  TBM  approach  [Ref.  38:p.  5].  This  was  an  extension  of  the  TC2-21  study, 
where  the  architectures  were  more  fully  developed  and  analyzed. 

c L  Artificial  Intelligence 

Expert  systems  and  artificial  intelligence  can  be  used  as  database 
management  and  information  decision  tools.  Recalling  the  concepts  of  push  and  pull  of 
information,  rule  sets  can  be  established  to  automatically  route  information  to  a 
commander.  The  rule  set  can  be  established  in  advance,  and  information  placed  into  the 
ether  can  be  tested  against  the  rules.  A  simple  example  would  be  the  use  of  key  words, 
similar  to  the  way  information  is  cataloged  for  libraries.  If  the  conditions  specified  are 
met,  the  information  is  sent  to  the  commander.  Otherwise,  the  information  can  be  stored 
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for  possible  later  retrieval.  In  this  way,  the  commander  can  pre-filter  incoming 
information  so  that  only  the  information  of  interest  actually  arrives  at  his  desk. 

4.  Conceptual  Clarity 

A  recurring  theme  throughout  this  research  has  been  a  sense  of  confusion  over 
how  the  different  pieces  of  the  puzzle  fit  together:  the  relationship  between  master  plans 
and  architectures,  the  relationships  between  different  architectures  (technical,  functional, 
or  those  in  support  of  a  specific  CINC  or  major  command),  and  the  relationships  between 
architectures  of  different  services.  Logically,  there  should  be  a  natural  nesting  of 
architectures  from  one  level  to  the  next  At  the  risk  of  over-simplification.  Figure  20 
shows  how  service  architectures  could  be  pieced  together  to  form  a  CINC  architecture. 
Further,  using  the  Air  Force  segment  MAJCOM  architectures  can  be  joined  to  form  the 
service  architecture.  The  functional  areas  are  represented  as  ellipses;  they  span  the  entire 
theater,  and  are  represented  within  each  service/MAJCOM  architecture  as  well. 

Sub-architectures  can  taken  down  to  the  desired  level  of  detail,  with  the  caveat 
that  connections  to  other  parts  of  the  parent  architecture  remain  clear.  In  a  sense,  the  sub- 
architectures  would  be  modules  that  plug  into  the  parent  architecture.  Sub-architectures 
would  also  be  cascaded  to  ultimately  form  the  support  structure  required  by  the  CINC. 

Interoperability  should  be  treated  as  an  issue  within  an  architecture,  not  as  an 
architecture  itself.  Interoperability  between  systems  is  a  design  goal  that  can  be  served 
through  clear  architectural  concepts.  Interoperability  concerns  occur  wherever  a  boundary 
iscrossed.  This  could  be  between  functional  areas,  services,  or  commands.  Defining  the 
standards  at  the  boundaries,  and  enforcing  compliance  ensures  systems  will  interoperate. 
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Figure  20:  Architectural  Concepts 
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A  factor  that  compounds  these  conceptual  problems  is  that  the  word 
"architecture"  does  not  have  a  universal  meaning  within  the  DoD.  JCS  Pub  1-02  does  not 
have  an  entry  for  architectures,  and  dictionaries  are  not  always  consistent  with  each  other. 
This  has  led  to  many  different  interpretations  of  the  word  and  corresponding  confusion 
over  what  should  be  in  an  architectural  document  [Ref.  38:pp.  2-3]  A  proposed 
definition  is: 

A  guide  or  "blueprint"  which  outlines  the  shape  and  structure  of  a  system,  or  group 
of  systems.  It  provides  a  goal  to  build  toward,  and  shows  the  boundaries  between 
systems  and  the  standards  used  at  the  boundaries. 

The  essential  elements  are  structure  and  standards.  It  should  be  clear  to 
anyone  reading  an  architectural  document  what  would  be  required  for  them  to  interface 
with  it 

5.  Systems  Training 

Part  of  the  difficulties  facing  deployable  systems  may  stem  from  a  lack  of 
training  in  "systems"  themselves.  As  stated  in  Chapter  I,  systems  are  more  than  just  the 
sum  of  their  parts,  and  are  characterized  by  interdependence  of  elements.  Engineers  and 
technicians  need  to  understand  the  individual  pieces  of  equipment  but  maybe  even  more 
important  is  an  understanding  of  how  that  piece  of  equipment  contributes  to  the  overall 
network,  and  the  impact  to  the  network  if  that  equipment  is  dysfunctional.  This  is 
especially  important  since,  as  they  progress  in  their  careers,  these  same  people  will  be 
responsible  for  designing  and  implementing  new  families  of  equipment. 
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C.  THE  MISSING  LINK 


Integrating  deployable  communications  systems  will  not  be  easy;  otherwise  the 
problem  would  have  been  solved  by  now.  But  from  a  systems  standpoint,  it  appears  that 
many  of  the  problems  are  more  organizational  in  nature  than  technical.  Fundamentally, 
this  means  that  the  physical  system  can  only  be  as  integrated  as  the  management  and 
organizational  infrastructure  behind  it.  Where  concepts  are  not  well  understood  or 
executed  in  organizations,  it  will  be  difficult  to  design  these  concepts  into  a  physical 
system;  the  finished  product  will  mirror  the  strengths  and  weaknesses  of  its  design. 
While  solving  the  small  problems  is  important,  the  task  still  remains  to  ensure  that  all  the 
solutions  are  integrated  and  that  the  total  product  produces  the  desired  system 
performance. 

In  the  goal  architectures,  the  Air  Force  has  asked  deployable  communications 
systems  to  perform  things  which  have  not  yet  been  solved  for  the  fixed  systems- 
compatible  data  formats,  for  example.  If  the  organizational  and  management  issues 
behind  data  formats  remain  unresolved,  the  best  of  equipment  will  not  solve  the  problem. 
Simply  providing  a  personal  computer  to  Oscar  Madison  (of  the  "Odd  Couple")  will  not, 
in  itself,  make  him  an  organized  person. 

If  this  thesis  can  leave  the  reader  with  a  better  appreciation  for  the  underlying 
causes  of  persistent  integration  problems  with  deployable  communications  then  its  goal 
has  been  reached.  Possibly  the  single  most  important  concept  could  be  that  the  way 
systems  are  fielded  is  just  as  critical  as  the  system  itself.  Study  after  study  can  determine 
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where  technical  problems  lie  and  recommend  solutions,  but  without  a  coherent  mechanism 
to  implement  to  solutions,  the  best  plans  will  never  be  fully  realized. 

D.  SUMMARY 

The  technical  problems  facing  deployable  communications  systems  today  are  fairly 
well  characterized  and  understood.  The  solutions  lie  in  developing  interfaces  to  allow 
existing  equipment  to  interoperate,  while  at  the  same  time  reaching  toward  a  goal  of 
greater  use  of  common  standards,  open  systems,  modular  equipment,  and  distributed 
processing.  But  if  the  goal  of  integrated  systems  is  to  be  reached,  the  management 
structure  which  spawns  the  system  must  itself  become  integrated.  This  author  is 
optimistic  that  both  goals  can  be  reached. 
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APPENDIX 


THEATER  BATTLE  MANAGEMENT 
GENERAL  OFFICER  STEERING  GROUP/WORKING  GROUP 

CHARTER 

1.  PURPOSE:  This  Charter  defines  the  membership  of  the  Theater  Battle  Management 
(TBM)  General  Officer  Steering  Group  (GOSG)  and  its  subordinate  TBM  Working  Group 
(WG). 

2.  SCOPE:  Theater  Battle  Management  is  broadly  defined  as  that  function  of  AF 
command,  control,  communications,  and  intelligence  (C3I)  which  supports  the  rapid 
acquisition  and  reliable  processing,  correlation,  and  dissemination  of  information  required 
for  decision  making  in  support  of  theater  operations  at  all  levels  from  command  battle 
management  to  the  mission  planning  and  execution  levels.  TBM  is  focused  on 
automation  of  processes,  integration  of  systems,  and  interoperability  of  hardware, 
software,  and  procedures  which  direcdy  or  indirectly  affect  the  speed  and  efficiency  of 
tactical  and  strategic  force  execution.  The  program  will  orchestrate  the  fielding  of 
selected  C3I  projects  through  rapid  prototyping,  evolutionary  acquisition,  and  continuous 
user-developer  interaction.  The  TBM  C3I  goal  is  to  improve  our  warfighting  ability 
through  (1)  accelerating  information  flow  to  the  commanders,  (2)  providing  more  timely 
information  for  decisions,  (3)  providing  better  decision  support,  and  (4)  decreasing  the 
tasking-to-execution-to-retasking  cycle  times. 

3.  ORGANIZATION:  The  GOSG  is  supported  by  the  TBM  WG,  which  provides  a 
forum  for:  (1)  working  issues  assigned  by  the  GOSG,  (2)  developing  recommendations 
for  inclusion  of  selected  efforts  within  the  TBM  program,  (3)  providing  activity  reports 
to  each  GOSG  meeting,  and  (4)  exchanging  information.  Neither  the  GOSG  nor  the  WG 
is  intended  to  supplant  existing  staff  organizations/groups  dedicated  to  resolving  TBM 
problems,  but  rather  to  provide  cross  functional  guidance  and  policy. 


a.  GOSG  membership  is  comprised  of  AF  customers  (TAC/DO,  PACAF/DO, 
MAC/XO,  AFSOC/CV,  AFIC/CV,  and  AFSPACECOM/DO),  requirements  developers 
(TAC/DR,  MAC/XR,  SAC/XR),  and  suppliers  (AFSC/XR,  AFCC/CC,  ESD/CV,  and 
SSC/CC).  The  chairman  is  TAC/DR.  Other  agencies  are  asked  to  participate  and  provide 
expertise  in  areas  of  interest  to  the  AF  and  include  representatives  from  the 
MAJCOM/IN/SC/XP,  SAF/AQP,  AF/XO/IN/SC,  and  the  suppliers/laboratories  such  as 
ASD,  ESD,  Rome  and  Armstrong  Labs,  and  the  TIC.  The  Secretariat  is  TAC/DRI. 
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TAC/SCP  serves  as  technical  advisor  to  the  Secretariat.  Responsibilities  for  day-to-day 
decision  making  will  be  delegated  to  the  TBM  WG. 

b.  The  General  Officer  Steering  Group  will: 

(1)  Serve  as  the  governing  body  to  set  policy  for  the  theater  operators  on 
procedures,  terminology,  direction  and  scope  of  TBM  activities  and  establish  priorities  for 
requirements. 

(2)  Provide  direction,  guidance,  and  support  for  TBM  initiatives  and  C3I 
automation  efforts. 

(3)  Establish  focal  points  for  resolution  of  problems/issues  regarding  TBM 
systems’  requirements,  funding,  development,  fielding,  and  the  connectivity  between  other 
systems. 

(4)  Serve  as  the  sponsoring  group  for  the  TBM  WG. 

(5)  Confirm  decisions  of  the  TBM  WG. 

(6)  Meet  twice  a  year  (or  as  required). 

c.  Associate  (ex  officio)  membership  will  be  extended  to  the  Army,  Navy,  and 
Marines.  Their  participation  will  be  as  observers/advisors  as  required. 

d.  The  TBM  Working  Group  membership  is  comprised  of  customer  representatives 
from  appropriate  TAC,  PACAF,  USA  FE,  MAC,  SAC,  AFSOC,  AFIC,  and 
AFSPACECOM  program  offices  (both  functional  and  technical),  interested  air  staff 
(SAF/AQP/ACT,  AF/XOO/XOR/INX/SCM),  suppliers  (AFSC,  AFCC,  AFCSC,  ASD, 
AWS,  DMA,  ESD,  SSC,  Rome  and  Armstrong  Labs),  and  joint  services  (equivalent 
user/developer-level  representation).  As  with  the  GOSG,  TAC/DRI  is  the  Secretariat. 
The  group  may  establish  one  or  more  subgroups  tailored  to  address  specific 
programs/issues  assigned. 


e.  The  Working  Group  will: 

(1)  Work  issues  assigned  by  the  GOSG. 

(2)  Review,  prioritize,  and  approve  TBM  needs. 

(3)  Monitor  TBM  programs  under  development. 
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(4)  Oversee  TBM  laboratory/testbed  developments. 

(5)  Review  advanced  TBM  technology  and  command-unique  TBM  programs 
for  AF  applicability  and  recommend  candidates  for  rapid  prototyping  considerations. 

(6)  Define  specific  TBM  interoperability  issues  and  propose  solutions. 

(7)  Confirm  decisions  of  subordinate  working  groups. 

(8)  Meet  as  required. 
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LIST  OF  ACRONYMS 


ABCCC 

ACC 

AF 

A-FAC 

AFCC 

AFCC/COMAFFOR 

AFCH 

AFCSC 

AFIC 

AFSC 

AFSOC 

AFSPACECOM 

ASD 

ASOC 

ATO 

AWACS 

AWS 


Airborne  Command  and  Control  Center 
Air  Component  Commander 
Air  Force 

Airborne  Forward  Air  Controller 
Air  Force  Communications  Command 

Air  Force  Component  Commander/Commander  Air  Force  Forces 

Air  Force  Component  Headquarters 

Air  Force  Cryptologic  Security  Center 

Air  Force  Intelligence  Command 

Air  Force  Systems  Command 

Air  Force  Special  Operations  Command 

Air  Force  Space  Command 

Aeronautical  Systems  Division 

Air  Support  Operations  Center 

Air  Tasking  Order 

Airborne  Warning  and  Control  System 
Air  Weather  Service 


C2 

C3 

C*I 

CAFMS 

CALOW 

CCS 

CINC 

CONUS 

CRC 

CRP 

CSAF 

CTAPS 

CVSD 


Command  and  Control 

Command,  Control,  and  Communications 

Command,  Control,  Communications,  Computers  and  Intelligence 

Computer  Assisted  Force  Management  System 

Crisis  and  Limited  Objective  Warfare 

Communications-Computer  System 

Commander-in-Chief 

Continental  United  States 

Control  and  Reporting  Center 

Control  and  Reporting  Post 

Chief  of  Staff  of  the  Air  Force 

Contingency  TACS  Automated  Planning  System 

Continuously  Variable  Sloped  Delta 


DCS 

DCS  A 

DGM 

DISA 

DMA 

DoD 


Defense  Communications  System 

Deployable  Communications-Computer  Systems  Architecture 

Digital  Group  Multiplexing  equipment 

Defense  Information  Systems  Agency 

Defense  Mapping  Agency 

Department  of  Defense 
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ESD 

Electronic  Systems  Division 

FACP 

FACRP 

FLOT 

Forward  Air  Control  Post 

Functional  Analysis  and  Consolidation  Review  Panel 
Forward  Line  of  Troops 

GOSG 

GMFSC 

General  Officer  Steering  Group 

Ground  Mobile  Forces  Satellite  Communications 

ITN 

Information  Transfer  Node 

JCS 

me 

Joint  STARS 

Joint  Chiefs  of  Staff 

Joint  Interoperability  Test  Center 

Joint  Surveillance  Targeting  Attack  Radar  System 

KBPS 

Kilobits  per  second 

MAC 

MAJCOM 

MBPS 

MCE 

MOB 

MPC 

MTACC 

MTI 

Military  Airlift  Command 

Major  Command 

Megabits  per  second 

Modular  Control  Element 

Main  Operating  Base 

Message  Processing  Center 

Modular  Tactical  Air  Control  Center 

Moving  Target  Indicator 

NCA 

NTB 

National  Command  Authorities 

National  Test  Bed 

OSD 

Office  of  the  Secretary  of  Defense 

PACAF 

PCM 

Pacific  Air  Forces 

Pulse  Code  Modulation 

SAC 

SAF 

SATCOM 

SHF 

SSC 

Strategic  Air  Command 

Secretary  of  the  Air  Force 

Satellite  Communications 

Super  High  Frequency 

Standard  Systems  Center 

TAB 

TAC 

TACC 

Tactical  Air  Base 

Tactical  Air  Command 

Tactical  Air  Control  Center 
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TACS 

Tactical  Air  Control  System 

TACP 

Tactical  Air  Control  Party 

TADIL 

Tactical  Data  Link 

TBM 

Theater  Battle  Management 

TC2-21 

21st  Century  Tactical  Command  and  Control 

TIC 

Technology  Integration  Center 

TPFDL 

Time  Phased  Force  Deployment  List 

TRI-TAC 

Joint  Tactical  Communications 

USAF 

USAFE 

USAFTC 

United  States  Air  Force 

United  States  Air  Forces  Europe 

United  States  Air  Force  Tactical  Communications 

woe 

Wing  Operations  Center 
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